Sheet, GyroGears and Apache follow up

Concept Framework was missing a nice Grid control. After some searches I came over GtkSheet in gtk-extra-2.0. A very nice set of controls, but with some problems on windows. I've took some file from the CVS and is working fine now. I've made a test application for reading Excel files:

Works fine with excel 97-2003 files, bot doesn't support images (however the grid does, and you can insert virtually any control - buttons, charts, etc.).

Also I've made the grid available in GyroGears via the long string data type, with the "Sheet" option. Here is a sample screen shot from a Gyro application:

In the previous post I've talked about the caching on Apache HTTPD2. I've made some nice charts (in Concept) that illustrate the server response time for cached csp scripts, static html and cached csp.

I've ran the test several times and isolated the first run and the best run. As you can see, for Cached CSP the delivery time is slightly better from the static HTML. And some random key were generated to memcached to emulate a real-world situation.
I've activated the engine on www.booha.ro , and the optimization is now dramatic.

Its awesomeness, Apache HTTPD2

I've been working a lot in the last few days. I've added a GeoIP wrapper for Concept, documentation available at http://www.radgs.com/docs/help/GeoIP.html. Nice library by the way.

Now, for the cool stuff. I was thinking how much content is served to all the visitors ... and that content is cached by memcached to reduce workload ... but I think I can go further - direct caching from the web server. Let's see in the pretty colored schema bellow.


Let's say that an user (Client1) makes a request to Apache HTTPD. The server will call ConceptCGI to process the request, and the script will access a memcached server for caching data. But, if we cache the whole page, images, etc., why is a need for the CGI to run? Well, it isn't. For that I write an Apache module (mod_conceptcache) that allows the server to serve cached memcached data very fast, so fast that Client 2 will access cached data very fast without generating any significant CPU or memory usage on the server - and that's critical because the server can serve more users using the same resources. I've set some nice APIs for the back-end, the programmer being able to explicitly cache data for visitors, users or locations (as you can see in the figure, mod_concept_cache is linked to GeoIP). Documentation is available on http://www.radgs.com/docs/help/ApacheCacher.html.
GyroGears is already aware of this, and generates code for the http back-end using ApacheCacher.

PS: Fast = tens of times faster

SQLite now in GyroGears

Added SQLite on the list of supported servers in GyroGears. Now GyroGears is tested on MySQL, PostgreSQL, Firebird and SQLite. Oracle XE support will be available soon.

HTTP as a transport layer

I've implemented two modules - one for Concept Client and another for Apache HTTPD 2 that allows concept:// packages to be transported over http://. It uses GET for receiving data from the Concept Application Server and POST to send the concept:// binary package. This is the first step towards the Concept://JavaScript Client that will use the concept:// protocol over http://.
The main benefit of using http:// as a transport layer is that connection can now be stateless, although is a little bit slower than the concept:// standard protocol. Another major advantage is on firewalled networks that allow only HTTP traffic.