Wednesday, June 21, 2006


EJAX: why the response architecture

In the previous posts I explained that the EJAX page formatter takes an existing HTML page and a collection of responses and emits that as the HTML page to the browser. There is another reason for this architecture and that it is now easy to implement load-balancing and improve responsiveness.

The reason is that we can select not to apply or generate a response when the page is requested, but defer that. For example we could insert an iframe with a URL to a reponse. The browser will request that iframe when the page has loaded and we can make the page (inter)active before waiting for that response. Or we could use XHR (XmlHttpRequest), or AJAX, to retrieve portions of the page in the background, asynchronously.

The responses can come from different servers as well of course. All this helps to achieve a page that appears faster: it is generated faster because less processing is done on the server, and it appears faster on a user's screen because it is smaller: less bytes to send over the network.

So the proper architecture gives us options at deployment time. Depending on if we're serving a local network or to browsers on a mobile phone, we can target what portions of the page to send now and what to send later.

For the record, this is all easily supported by the Goanna Application Library architecture as well.
Berend: I have nothing substantive to add, but just want to comment that I am enjoying seeing these design issues discussed here.

Often, we are presented with a design as a "fait accompli" but it's nice to see the issues being aired during implementation.
Hi Neal,

One of EJAX's goals is to be independent of an implementation framework, because I would like to be able to switch from eposix CGI to Goanna FAST_CGI.
The design issues you've been discussing are quite removed from the CGI/FAST_CGI level. Switching from eposix CGI to Goanna FAST_CGI should be fairly trivial. Being able to switch an application back and forth from eposix CGI to Goanna FAST_CGI would be a bit more work. You would need some kind of bridge between your framework and the GOA_FAST_CGI_REQUEST and GOA_FAST_CGI_RESPONSE classes. Now, the notion of GOA_HTTP_SESSION (cookie based) is pretty well baked into Goanna, but you don't have to use it (actually, it shouldn't be too difficult to make that a configurable option in Goanna).
The thing I don't like about the Goanna architecture is you are forced to choose a connector (CGI, FastCGI or standalone web-server) at compile time. This ought to be an initialization-time decision.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?