Internet Alchemy

So I’ve arrived in Cannes for the W3C Tech Plenary and 1 hour in my laptop hard disk fizzled out. Which makes several things rather tricky… I think the boot info has been corrupted. I’ve fixed this before by using a bootable Linux CD but I forgot to bring it Are there any kind souls in the area who have a bootable Linux CD or can bring one? Email me at iand at internetalchemy.org or phone me on +44 7966 473239. Thanks.

Sometime you need to make extreme statements to make a subtle point clearer:

It doesn’t matter how easy it is in [awesome VisualStudio/RubyOnRails/Python/IntellijIDEA]. It has to be easy in COBOL.

Robert Sayre on the permathread that is REST vs WS-*

An oft-forgotten feature of PHP is its shared-nothing architecture as pointed out in this pro-PHP rant (countering all the PHP bashing going on at the moment):

…the important thing to take from that (compared to mod_perl / mod_python / mod_* or even “X” application server.) is the interpreter returning to a fresh state after every request (no globals hanging around or otherwise)

A fresh state every time - which means you can load balance across any number of PHP servers without the complexity of session state synchronisation or server affinity. Infinite horizontal scaling.

Addendum: Another benefit of fresh execution state on each request is that it’s very hard to crash the system, which goes a long way to explain why PHP is ubiquitous in cheap hosting environments:

With PHP it’s very hard for a script to take down the runtime environment—the web server—I’d argue that you’d have to be deliberately trying to do so, perhaps filling up disk space or otherwise. Innocent mistakes, specific instances of runtime problems (e.g. script execution too long) and bugs remain local to specific requests and the PHP script handling them. On the next request, we begin again from scratch.

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.