In the part 1 of this article I presented a summary of the disadvantages that I think the current model of communication between the browser and the server has (where the browser-server can be any combination of implementations you can think of).
In my opinion the current dialog protocol is no longer sufficiet for the needs of many of the applications that we build today. We inherited the HTTP protocol and the HTML language from the days when getting a document from the server was all there was needed, and currently we are trying to turn this document-fetching operations into something interactive, something that works just like a desktop application. But it doesn’t, and those applications that do look interactive/snappy/web2.0 are just fully loaded with Ajax and JavaScript on the browser side, and hard core workarounds and tons of libraries on the server side.
When I say “interactive” I refer to the form of dialog where the user is working directly with the window or the dialogs that he/she sees, where clicking on the Save button makes the data persistent in the storage and I can keep working on my current tasks in the application, where I can minimize applications to taskbar or to system tray, where I can create shortcuts to my applications on the desktop, where I can have my “.xyz” files opened with that application, and so on. All this directly through the browser.
Sure, we can have many of these implemented using Ajax and JavaScript, but as I said on part 1, this is a simulation for both users and developers.
Changing this
First of all we have applications nowadays that are fitting the old document-request model really well. Documentation sites, company advertising sites, presentation sites, personal sites and so on cope very well with this type of dialog, so the new browsers and servers should still be able to support the old model.
The new dialog model I believe should be based on a binary format. The data that will be transferred between the server and the browser will be quite large, so compression should be available. Also security will be enhanced if the format is binary.
Next the browser should be implemented in such a way so that it is able to create new modal windows, panels, dialogs, list boxes and so on based on the information received from the server. The classical buttons like Home, Refresh, Back, Forward must be removed, since it doesn’t make sense to use them in such applications. Everything starts from the main window, where you get the basic data, and then you start doing your work with the elements from that window, open panels, save data, add/remove/edit items and so on. You don’t need to get to the next page or return to a previous one because… there is no previous one.
Since the client is working in one place and the server is some other and distant place, the connection between them might fall at any moment. The browser should be prepared to take the application offline, store the data locally in some internal database, and then, when the connection to the server is re-established, synchronize the data and transfer the items created during the offline session back to the server. This should be transparent to both the user AND the developer. Of course, when the application is taken offline, the user should be notified that several services or functions of the application are no longer available until the connection is back online, because the data that was fetched from the server-side storage is available locally, but any additional data cannot be fetched from the server since there is not connection available yet.
The development model for the client side should be as simple and straightforward as possible. Glue code and classes should be provided for making the connection between the code for the client (/browser) and the code from the server.
On the server side things are not as different as they should be on the client side. However, a framework or again some glue code should be provided in order to make the connection with the code from the client side. This framework/glue-code should also handle gracefully the part with the synchronization of the data from the client with the data from the database, after a session of dropped-connection/offline-working.
How about Flex and GWT?
True, Adobe Flex and GWT are two technologies that provide some of the features that I want from the new model (of course, there might be other technologies besides these two, so please add a comment if you know some more). However, what they really do is to create just another layer on front of the users and the developers in order to hide the fact that every click results in a Ajax call or in a hidden iFrame being refreshed.
And Google Gears?
Yeap, Google Gears is an example of how the browser should handle the dropping of the connection between the browser and the server. But something that I think Gears doesn’t have (yet) is a mechanism for automatically handling the synchronization of data between the client and the server. How can this be done? I am not sure, perhaps by recording the actions performed by the user, and the replay them to the server once the connection has been re-established. This will ensure maximum transparency for the client code, and for the server the things will look just like they are being performed by the user operating the client very fast. But anyway, this is just an idea, probably a much better solution could be designed for this.
I was writing a while ago about 
.