coffee, black   no sugar


20061014 Saturday October 14, 2006
web events and url templates

In his recent posting Mark pointed to an article by Graham Klyne about inter portlet communication.

The interesting aspect (to me) of the article is the piece about a web event mechanism which can be used by servers to announce events to clients such as browsers. This would enable a better and easier synchronization of multiple views on the same model (among other things obviously).

Current Ajax applications follow the MVC insofar as they render (often multiple) views in a single HTML page. Often views share the same model. The basic update mechanisms I have seen so far are:

  • plain polling: each view periodically polls the server for new content
  • Json combined poll: the javascript polls periodically for the interesting (part of the) model and a copy is sent back as plain data to the client. Here the script slices it and updates its views accordingly.
The first and very simple solution is, well, simple, but does not scale that well. Additionally, it lacks synchronization between views. So one view shows a data update and the HTML next to it show the old data. So user get confused and have to wait for the changes to stabilize in order to make sense of what they see.

The Json polling avoids these problems, but at quite some cost. The client side scripting gets much more heavy. More costly to implement and debug. But also more costly to change and evolve.

I am currently thinking of a hybrid approach for a project of mine where a single pull is done by a client and the server responds with aggregated HTML slices for each view. In this way, views are synchronized and client side scripting can be kept light.

But back to Graham (you have read his posting by now? fine!). What he proposes sounds like another scripting thing, but it is not. He proposes to use scripting for the initial implementation. The real architecture, as I read him, is:

  • a defined event protocol between client and server
  • a declarative way to point the client to the event url (meta tags, headers would be better)
  • some extensions in DOM so that scripting can make use of it, some extensions to HTML to allow for scriptless updates (this is my extrapolation)
The beauty of this that once it is implemented natively in the browser, the updates can be painlessly synchronized between multiple windows, just by seeing that two windows share the same event source url. Neat, I want that.

I have the feeling that this event protocol could be a mix of HTTP and some XJson (ha! eXtendend Json or Xml Json? I won't tell!). Let me explain:

  • The "event source" is a url like http://server/views?v1+v2... (maybe a template?)
  • The browser builds the url out of the page needs. Multiple pages with the same url (template) share the returned data. The needs are either declared in the HTML or registered by scripts.
  • The browser request the url representation and expects data slices named "v1", "v2" and so on. The sliced data pieces are then returned to the scripts or directly used to update the page (could be a HTML fragment).
If one makes sure that the url has a canonical form (view names are alphabetically sorted for example) HTTP caches will help scaling a lot.

Technorati Tags: ,

google reader

I just gave google reader a ride and it is a nice piece of work indeed. The interface is clear and simple, keyboard navigation is fine etc. And of course: it just works in 10 seconds.

It is of course unable to read authenticated feeds, not that I wanted to give it my credentials in the first place. So, I think I will not use any online reader for the time being.

But if I would, google reader would probably be it. I especially like that feature that items are marked as read when you scroll by. Very tricky for a web ui.

Technorati Tags: