W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2005

[whatwg] Some likeness of DOM Session scope

From: Olav Junker Kjr <olav@olav.dk>
Date: Thu, 21 Apr 2005 16:49:59 +0200
Message-ID: <4267BD97.60707@olav.dk>
Ian Hickson wrote:
> I entirely agree that this is a good idea. I'm not 100% sure what a good 
> way to do this is. Some sort of per-domain, per-window (tab, in modern 
> browsers) object that is shared across pages from that domain is what I 
> had in mind, but I'm not sure what the object should do. I was considering 
> having it be a DOM (so basically you stored data in an XML document), but 
> that seems unwieldly. I also considered just a list of strings, but that 
> seems too unstructured. An object containing object references wouldn't 
> really work other, because there's no way to serialise it (so that it 
> lasts longer than the current browser session, e.g.).
> 
> Anyone have any concrete proposals? :-)

How about a javascript structure which may be arbitrary deep, but only 
may contain javascript built-in types (Object, Array, string, number, 
bool, Date etc.)? This would be very easy to use, although it might be 
confusing for authors that you can save a string but not e.g. a textnode.

There is some larger issues here, though.

A web page with an URL should be "reentrant", e.g. if you bookmark it 
and visit it later, it should work. Pages which is dependent on info 
generated on other pages should either have that info encoded in the 
URL, or be accessed through a POST request. In the first case, the 
context is preserved, in the second the page can't (easily) be 
bookmarked and revisited, since browsers treats pages which is the 
result of a POST request differently, which avoids the problem of the 
missing context.

Ordinary web sites are usually "stateless" in the sense that you can 
visit the pages in any order. Stateful transactions (like payment) are 
usually handled as a sequence of POST's.
Web applications on the other hand are usually very stateful, but 
precisely because they are usually confined to a single page with a 
single URL, you dont get the "reentrance" problem. You can only bookmark 
the initial state, which is safe.
If an app spans several pages with distinct URL's, but is stateful in 
such a way that pages are dependent on local state generated on earlier 
pages, it gets very fragile. We might start to see lots of "You seem to 
be visiting this page out of context" messages on Google :-)

Thats not to say that the proposal is a bad idea. I see some very strong 
use cases for it. For example, I might have written half a page of text 
in a CMS, but when i hit "save", I'm informed that the network 
connection is broken, and it wont get fixed before monday. In this case 
it would be very nice if the client side script could save data in a 
persistent local store - only accesible to this page, of course.

regards
Olav Junker Kj?r
Received on Thursday, 21 April 2005 07:49:59 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:40 UTC