W3Kit provides both the developer and the user with the familiar metaphor of an event-driven graphical user interface, but in the novel distributed setting of the World Wide Web. To both server and client, the application appears to consist of interface `widgets' which respond to events and send messages to other widgets or objects. The graphical widgets also appear to be capable of sophisticated interactive 2D and 3D graphics.
This is an illusion in two main respects. First, the HTTP protocol is stateless. Connections to the server are made only at the user's request, and between connections, the server end of the application exists only in the user's imagination. The HTTP server is not expected to maintain any information for or about individual users. Second, the HTML format actually supports only simple bitmap images as graphics. The server is responsible for translating any higher-level graphics into this format.
Figure 1. The illusion.
How does W3Kit maintain these illusions? Let's follow the process step by step.
In order for the server to be able to `remember where it was', information about the state of the application must be stored on the client side. W3Kit accomplishes this in a flexible and unobtrusive way by hiding `freeze-dried' copies of the server's Objective-C objects inside the HTML document returned to the user.
The exact mechanism for storing this object archive in HTML depends on the level of HTML support assumed of the client. The most modern version uses special `hidden' fields which are designed for this very purpose. Note that since the internal state information is entrusted to the client, some security considerations may arise. For example, W3Kit takes some care in regard to remembered file names.
Figure 2. Client-side caching of application objects.
When the user makes a request, for example by clicking on a graphical input widget, the client packs up all the relevant input fields and sends them to the HTTP server. The HTTP server starts up the application's CGI script and passes on to it these packed-up input fields.
At this point, W3Kit intervenes to set up the illusion on the server end. First, W3Kit reconstitutes the freeze-dried application objects, along with all of their interconnections, from the hidden archive. Second, W3Kit runs a simulated `event loop', sending messages to each of the interface widgets to inform them of the new values of the input fields returned by the client.
In response to these event messages, the widgets can automatically send messages to other application objects to which they are connected. These effects ripple throughout the application, updating all of the objects in accord with the user's new request.
Figure 3. Reconstituting the application and running the event loop.
After all the event messages have run their course, it is time to return the updated interface to the user. It is at this point that W3Kit takes a snapshot of the objects, freeze-drying copies of them for secret insertion into the returned interface form.
With the application state safely cached, W3Kit assists behind the scenes as the new interface is being printed out in HTML. Graphical widgets are not asked to print themselves in HTML; instead they can use an appropriate graphics language (PostScript for 2D, MinneGraphics for 3D), and W3Kit will route these calls to the appropriate display server. When printing is completed the application shuts down.
Figure 4. Freezing application state and printing the new interface.
During printing, W3Kit retrieves the graphics from the display server, and makes them available as image files for later retrieval by the client. The final step in the process is for the client to display the new interface, including the new inline graphics which are retrieved separately.
Figure 5. Inlining the new graphics.
(Note: The figures in this document are taken from a talk I gave at the Keck Center for Genome Informatics.)
Author: Paul Burchard
Comments to: firstname.lastname@example.org
Created: Apr 18 1994 --- Last modified: Jun 18 1996