[whatwg] Window id - a proposal to leverage session usage in webapplication
mikewse at hotmail.com
Thu Feb 18 03:07:04 PST 2010
[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
> 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
I made an overview of this last year , 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
browsing context WS sessionStorage - *
document - -
history entry push/replaceState N/A
(#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.
More information about the whatwg