[whatwg] some feedback on Web Apps 1.0 client-side storage

[Robert O'Callahan]

On 08/09/05, Ian Hickson <ian at hixie.ch> wrote:
> 
> On Thu, 1 Sep 2005, Robert O'Callahan wrote:
> > 3.4.2 "DOM Node objects" browser DOM nodes often have state that isn't
> > apparent in the DOM --- e.g., the contents of a <canvas>, or the state
> > of form controls. Please clarify that this state is not restored and
> > ONLY the listed attributes and children may be restored.
> 
> Added a note to this effect.


Actually I think you need a more general statement: that no state other than 
the state mentioned in the previous paragraph may be restored (which rules 
out canvas bitmaps etc). Otherwise it's not robust with respect to DOM 
extensions. I can see compatibility problems if some implementations 
accidentally or deliberately save and restore additional state, even if 
minor.

> 3.4.2 "other objects" this is entirely ECMAscript specific, is it not?
> 
> Not necessarily; I would expect a Perl binding to support this kind of
> thing for Perl hashes. Having said that, note that HTML5 in general has a
> strong JS bias, since JS is the Web's main language.


Sure but... 

> How can this work across language bindings? It might be a lot simpler
> > for everyone to only specify storage for DOM types.
> 
> It might be simpler for implementors, but I really think authors would
> want to be able to do things like:
> 
> globalStorage[document.domain].username = username;
> globalStorage[document.domain].lastVisit = new Date();
> globalStorage[document.domain].game = {
> name: 'fred',
> level: 42
> };
> 
> ...and so forth. Having to wrap stuff like that in E4X XML or (worse) DOM
> nodes just seems like an excessive amount of boxing.


Okay, but the problem then becomes what happens when one language sets a 
property and another language gets it: i.e. what you put in your note: "define 
how to take a JS Object and turn it into a Perl %hash, etc." --- without 
doing some N^2 conversion matrix. Avoiding the matrix means we have to 
specify some common format and how each of N languages maps to it. Now, what 
if the common format was --- hmm --- DOM nodes? :-) Then all we need here 
are JS convenience functions to convert simple JS object trees into some DOM 
representation and back again. We may or may not want to standardize those 
functions but I bet they're only a few lines of E4X to write.

An alternative is to define storage of simple JS object trees and then force 
all other languages to provide a mapping to and from that. I guess that'd be 
acceptable.

> 3.4.6.1 <http://3.4.6.1> <http://3.4.6.1> "The space limits on public 
> storage areas should
> > not affect the limits for non-public domains, however."
> 
> Changed that to a new suggested model based on the domain of the script
> setting the data, not the domain of storage area. Let me know what you
> think.


Is the domain of the script the domain where the script was loaded from, or 
the domain of the document in which it runs?

I have added text about this to the sessionStorage and globalStorage
> sections. (Short answer: sessionStorage: only when the window is closed or
> when you run out of disk space; globalStorage: only when the user says so.
> And in both cases, security concerns can trump everything and be used as
> an excuse to delete data whenever...)


Looks good. But I think developers would also like to be sure that the 
browser won't delete anything, say, while a script is running.

> -- There should be some atomicity property that authors can rely on to
> > safely update storage under potential failures (of the UA, or the
> > hardware, or whatever). It's probably enough to require that setItem and
> > removeItem are atomic with respect to failure. In other words, if the UA
> > fails during a setItem or removeItem, then later the operation will be
> > observed to either have succeeded normally or not happened at all (and
> > of course the storage object will not be corrupted!).
> 
> Good call. Added. Let me know if what I added is enough, though.


It looks good. That should let people build reliable storage without going 
the whole hog of transactions.

Rob
-- 
["Therefore, my dear friends, as you have always obeyed–not only in my
presence, but now much more in my absence–continue to work out your
salvation with fear and trembling, for it is God who works in you to will
and to act according to his good purpose." Philippians 2:12-13.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20050908/88c082a8/attachment-0001.htm>