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

[Ian Hickson]

On Thu, 8 Sep 2005, Robert O'Callahan wrote:
> > 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.

Ok, how about now? :-)


> > [Saving JS Objects]
> 
> 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.

Well, we don't need a common format, but we need a common model, yes.


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

It seems simpler just to use a common model that supports objects. :-)


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

http://whatwg.org/specs/web-apps/current-work/#domain0


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

Can we guarantee this? How about if the user empties their storage areas?

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