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

[Robert O'Callahan]

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.

3.4.2 "other objects" this is entirely ECMAscript specific, is it not? How 
can this work across language bindings? It might be a lot simpler for 
everyone to only specify storage for DOM types.

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." The definition of 
"public" is troublesome, as you note below. With this policy the most 
reasonable thing for implementors is to be conservative about what domains 
are declared "public" ... allowing denial of service attacks against sites 
in deeper/obscure public domains but preventing sites from grabbing 
unlimited storage. 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.

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

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

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/20050901/6116d934/attachment-0001.htm>