HTML Data Port

© 2005 Goetz Heller

Table of Contents Copyright Note back

Outline

The basic idea relies on a simple construct on the client side and is as follows:

In order to maintain state on the client side without having to send forth and back lots of state variables between client and server the client side part of the application application consists of a single HTML document called the client application frame. Some features such as header, footer, etc. may be fixed, and so are two special areas in the document. One is a div or an appropiately formatted table cell called the work area the contents of which are dynamically built by means on JavaScript. The other one is a hidden iframe called the HTML Data Port where the application-defined client-server communication actually takes place. This approach allows us to maintain state in the application frame and to make use of the server side session object in a more economic way - data traffic between client and server is greatly reduced. As a side effect, security is increased thereby. In particular, cookies are not needed for saving state information during a user session. If a client side page needs to be updated partially only that part of the page needs to be loaded, be it code, layout, or data. In addition, information exchange can be secured by authentication and encryption on top of the HTTP protocol. Data is exchanged between client and server via messages which can be encoded in various ways, say base 64 and/or some encryption. Therefore, the client part of the application consists just of a single HTML document which mutates over time without ever being reloaded. Needed functionality it lacks at some point of time can be loaded on demand, and receiving answers to requests does not force the document to be abandoned.

In order to achieve such a communication the client application frame creates an HTML document with a form inside the HTML Data Port. The form contains a field to which data to be sent to the server is assigned as its value ("request"). The data would be base64-encoded and optionally may be encrypted before.

The server side response is sent to the HTML Data Port in form of another version of an HTML document where the body text consists of the base64-encoded response data. Further information, e.g. a return code, maybe provided by some appropriately defined <meta≷ tags. The body's onLoad event handler calls a JavaScript routine inside the client application frame which in turn then starts processing the body content.

Clearly, this approach dictates the need of defining a protocol part of which is made of some general JavaScript functions inside the applicaton frame and a basic structure layout of the server response. Also, conventions for authentification and data encryption need to be established. The server side module responsible for code access will be called librarian - other modules will be identified as needed. The benefits of a librarian are immediately apparent:

Why? First, you probably need to rewrite your JavaScript scripting engine in order to see the source if its author did not provide for this. Second: You can configure your librarian such that it would not respond to unauthorized requests. In addition, the code sent to the client can be encrypted. Third: The client does not need to know where the code resides. If you want to reorganize your web site there is no need to update URLs - if only the librarian knows where to find the code. Fourth: Source code the location of which is not known cannot be tampered with. Actually, the librarian can be designed such that its URL is the only URL the client side must be aware of, together with an application id to append to this URL. This way, the librarian works as an application hub, or an application portal.

Another application could be such that the response data contains an HTML fragment which is used to replace the contents of the work area, or simply to change some data inside the work area be it visible or not. For instance, imagine a deeply neested hierarchy structure represented in a way a file system explorer would do. At the beginning, only the nodes on top of the hierarchy are expanded; the nodes below are collapsed. Hence there is no need to have all the hierarchy data inside the document at once. Instead, data is requested from the server only on demand - when a user wants to expand a node which has not been populated so far. Since in general only a fraction of all the nodes is visited by a user this saves a lot of network traffic.