[whatwg] Window id - a proposal to leverage session usage in web application

Hi all,

About half a year ago I came up with an idea to add a unique window id 
as request header to each browser request. I published this initially on 
my website
http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html

About a week ago, I have stumbled upon the WebApps Working Group which 
sent me over to the whatwg user group.

What is the idea about?
The browser should generate an id unique per browser window and sent it 
as request header with every browser request.
Request Header
--------------
X-Window-Id: 279078917624897

This allows to identify which windows sent a request and helps to 
leverage the use of the HTTP session in multi page web application. I 
will describe this in more detail below.

Why is it useful?
Imagine you want to use accordion style menus (sample: JQuery UI - 
http://jqueryui.com/demos/accordion/) or menu groups like the one of JSF 
Richfaces 
(http://livedemo.exadel.com/richfaces-demo/richfaces/panelMenu.jsf?c=panelMenu&tab=usage). 


If you want to show the same menus or widgets opened after a page 
reload, then you need to memorize somehow what is opened or closed. We 
need to keep track of the application's state.

Using the REQUEST
We could store the information in the request. As a consequence, every 
form and link of our screen needs to include a list of opened 
menus/widgets. This could be achieved by manipulating all links and 
forms using JavaScript.

The advantage is that it works with multiple windows and does not 
require a user session. The disadvantage is that it pollutes the request 
and enlarges the data sent by every request. In an application with a 
lot of stateful information it could be impossible to follow this approach.

Using the SESSION
The other solution is to store the state in the users session. Every 
time a menu/widget is opened, we send an Ajax request to keep track of 
opened menus. The downside of session usage is that it is impossible to 
use multiple windows in the browser because they would overwrite other 
window's state (opened menus). This is because a user session is 
normally stored as browser cookie and cookies are merged into a single 
space for all browser windows (new exception: secure browser windows)

Using the Window id
Having a window id, we can save the list of opened menus/widgets per 
window in the user session. We split up the user session in slices. In 
pseudocode it looks like this:
id = request['x-window-id']
context = session[id]
menus = context['menus']

It is quite interesting that HTML 5 solves the problem for the client 
side of JavaScript applications. The sessionStorage allows fine grained 
controll if data is seen by all windows or just by the current. The 
problem only persists for client ? server applications.

Another use case are dialogs or conversations which span multiple pages. 
We could think of a complex dialog to edit an item or the checkout 
process of a shop application. With a windows id, we know that the 
complex dialog was started in a window and that the user is now visiting 
another area. This allows to clean up the session area for this window.

I created a plugin for Firefox which adds the window-id to a request. 
You can use my ruby based sample application to test the be behaviour.

You can find the original article, the plugin etc in my blog.

http://www.laliluna.de/blog/categories/ideas/

I am looking forward to your feedback.

-- 
Best Regards / Viele Gr??e

Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de

Received on Thursday, 4 February 2010 12:49:14 UTC