- From: Mike Wilson <mikewse@hotmail.com>
- Date: Thu, 18 Feb 2010 12:07:04 +0100
[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 03:07:04 UTC