[whatwg] some feedback on Web Apps 1.0 client-side storage
rocallahan at gmail.com
Wed Aug 31 15:46:00 PDT 2005
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.
184.108.40.206 <http://220.127.116.11> "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.
18.104.22.168 <http://22.214.171.124> 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
-- 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!).
["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...
More information about the whatwg