[whatwg] some feedback on Web Apps 1.0 client-side storage
Ian Hickson
ian at hixie.ch
Wed Sep 7 15:55:27 PDT 2005
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list