- From: Olav Junker Kjær <olav@olav.dk>
- Date: Thu, 21 Apr 2005 16:49:59 +0200
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