RE: [whatwg] Window id - a proposal to leverage session usage in webapplication

[cross-posting as a similar amount of discussion has taken
place on the two groups]

Sebastian Hennebrueder wrote:
> 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

Right, I have also used this technique successfully since 
several years and it is quite a nice solution for managing
multiple windows. Though, currently this is only usable for 
Ajax apps (XHR.setRequestHeader) due to the missing pieces 
you point out.

> 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']

For other readers on the group it may be good to clarify that
this is the server side session you are talking about. The
whole point of adding this feature is to support server-
centric applications better.

> 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.

Exactly. Recent additions in this area of HTML5 mainly 
enhance the programming experience for applications that use 
script.

I made an overview of this last year [1], suggesting to
enhance the state handling model for server-centric apps. 
Below is a table with a related subset of the state
management features mentioned, and your suggestion would
fill the gap at *:

NON-URL-BASED STATE MANAGEMENT (FOR "GET" PAGES W/A)

Scope              Script-centric      Server-centric
-----              --------------      --------------
user agent         WS localStorage     http-only cookies
                   cookies             cookies
browsing context   WS sessionStorage   - *
                   window.name
document           -                   -
history entry      push/replaceState   N/A
within document
(#hash urls etc)

The response from Ian Hickson was in short to direct these
kinds of things to the HTTP WG, and that he expected 
applications to use Ajax-like interaction models instead.

It has since struck me that HTML5 is quite client-focused,
so I haven't invested time in bringing up any more server-
centric discussions. I do think there is a need though, to
cater for the classical server-side applications' state
management. But I am not sure what WG wants to do this.

Best regards
Mike Wilson

[1]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020423.html

Received on Thursday, 18 February 2010 11:08:01 UTC