W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

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

From: Sebastian Hennebrueder <usenet@laliluna.de>
Date: Thu, 04 Feb 2010 22:09:21 +0100
Message-ID: <4B6B3781.7030100@laliluna.de>
Tim Hutt schrieb:
> On 4 February 2010 20:49, Sebastian Hennebrueder <usenet at laliluna.de> wrote:
>> What is the idea about?
> 
> I think "Web Storage" does what you want and is already implemented
> (apparently even in IE). The description from the spec:
> 
> "This specification introduces two related mechanisms, similar to HTTP
> session cookies, for storing structured data on the client side.
> 
> The first is designed for scenarios where the user is carrying out a
> single transaction, but could be carrying out multiple transactions in
> different windows at the same time.
> 
> Cookies don't really handle this case well. For example, a user could
> be buying plane tickets in two different windows, using the same site.
> If the site used cookies to keep track of which ticket the user was
> buying, then as the user clicked from page to page in both windows,
> the ticket currently being purchased would "leak" from one window to
> the other, potentially causing the user to buy two tickets for the
> same flight without really noticing.
> 
> To address this, this specification introduces the sessionStorage IDL
> attribute. Sites can add data to the session storage, and it will be
> accessible to any page from the same site opened in that window.
> 
> For example, a page could have a checkbox that the user ticks to
> indicate that he wants insurance:
> 
> <label>
>  <input type="checkbox" onchange="sessionStorage.insurance = checked">
>  I want insurance on this trip.
> </label>
> A later page could then check, from script, whether the user had
> checked the checkbox or not:
> 
> if (sessionStorage.insurance) { ... }
> If the user had multiple windows opened on the site, each one would
> have its own individual copy of the session storage object."
> 
Hi Tim,

thank you for the feedback. I hope that I see your point correctly. You 
are right, that for JavaScript based applications this can easily be 
solved with a sessionStorage. All technologies around GoogleWebToolkit, 
Dojo, Echo etc which hold the state in the client and make use of a 
stateless server side application can use the session storage to 
distinguish browser windows.

But there are a lot of web technologies which hold the state on the 
server using the browser session. Technologies like Ruby on Rails, 
JavaServerFaces, Wicket, Struts, Tapestry to name a couple of them. 
Those technologies can not make a simple use of the session storage. 
They are only aware of the browser session which is a common space of 
all browser windows. The windows id let them split the session in a per 
browser window scope.

Originally, when playing with the window id concept, I simulated a 
window id by storing it in a session storage and adding it with the help 
of JavaScript as parameter to all links and as hidden field to all 
forms. It works to some extend but it pollutes the URL and is likely to 
cause problems with bookmarking and there is a use case where it fails. 
If you open a link in a new windows. In that case the first request is 
sending the wrong windows id.


-- 
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 13:09:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC