I'm in Oslo for a W3C working group face-to-face meeting. I've been doing some background research on the types of applications people are creating and came across this really neat calendar application written in dynamic SVG. I found the description of the development process fascinating especially the bit about the backend communication. It strengthens my belief that the balance of power is shifting once again, this time to a more even balance between the client and server. This style of development almost forces the application to be situated more appropriately in the web. Rather than the data api being hidden in the logic on the server, or in binary code in the client, it's exposed to the web for the client's use and more, importantly, reuse by future clients.

At the recent Future of Web Apps conference in London, Steffen Meschkat of Google said something quite interesting about another trend of the smart web application:

Client side session state - transient session state is managed on the client, while persistent user state is maintained on the server. This corrects a long standing architectural aberration. You don't need server-side session state any more!

(via Simon Willison's excellent notes)

He's talking primarily about using Javascript to manage state on the client side and this works well for single-page applications such as Google Maps, but less so for the multi-page AJAX applications that are out there. I think he's right in the general case: the smart web application is responsible for maintaining the state of the application, leaving the server to be responsible for managing resource state. When the application starts it fetches the persistent user state from the server and uses that to initialise itself, saving any significant changes back to the server periodically. This frees the server up from maintaining individual session state in memory which should improve concurrency and scalability of web applications.

I think there are a number of approaches to solving this problem for multi-page web applications. One is to enhance the browser to manage more useful storage, and this is in the charter of the Web API working group that I'm a member of. We're tasked to produce "An API specification for persistent storage on the client" and I'm currently nominated to edit that, a very exciting prospect.

Another way might be to encode some of the client state in the URL, specifically in the fragment identifier. The W3C Slidy application does this. It navigates to a new fragment of the current page on each slide transition. This has the bonus effect of giving URIs for individual slides, something that is missing with S5.

Maybe there are other ways too, perhaps using some kind of popup that holds the session data in a Javascript structure. Probably someone much more talented than me will devise a standard way of carrying over client state from page to page and package it so we can simply include it in our pages. Can't wait.