[whatwg] Some likeness of DOM Session scope
Olav Junker Kjær
olav at olav.dk
Thu Apr 21 07:49:59 PDT 2005
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? :-)
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
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.
Olav Junker Kjær
More information about the whatwg