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

Thanks for your feedback!

Diffs from what you read to what the spec says now are available at:

   http://whatwg.org/specs/web-apps/current-work/diff-2005-09-01#client-side


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.


> 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.


> 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.
   

> 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.


> Of course grabbing lots of domain names isn't unthinkable so UAs will 
> probably need additional mechanisms to manage quota. Some more 
> discussion of this problem would be helpful.

Added a paragraph on this.


> 3.4.6.2 <http://3.4.6.2> Is it obvious what "run to completion" means 
> for a script? I think here you need to say that the intended semantics 
> is that *as far as scripts can tell*, there is no concurrent script 
> execution, and hence no concurrent access to storage objects, and any 
> implementation technique that preserves this is allowed. If that's not 
> the intended semantics, it should be! The behaviour currently described 
> is one such technique but there could be others (e.g., optimistic 
> transactional script execution).

Changed that section to cover this.


> Two things that I didn't see that I think should be mentioned; apologies if 
> they are:
> -- From the security discussion, it's obvious that UAs are permitted to 
> arbitrarily discard persistent storage data. This should be stated up-front. 
> Exactly *when* is such discarding permitted, though?

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...)


> -- 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.


Thanks a ton for your help. Please let me know if you disagreed with 
anything here, in particular about the serialising objects vs only 
serialising DOM nodes thing.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 7 September 2005 15:55:27 UTC