On 08/09/05, <b class="gmail_sendername">Ian Hickson</b> <<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, 1 Sep 2005, Robert O'Callahan wrote:<br>> 3.4.2 "DOM Node objects" browser DOM nodes often have state that isn't<br>> apparent in the DOM --- e.g., the contents of a <canvas>, or the state<br>
> of form controls. Please clarify that this state is not restored and<br>> ONLY the listed attributes and children may be restored.<br><br>Added a note to this effect.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 3.4.2 "other objects" this is entirely ECMAscript specific, is it not?
<br><br>Not necessarily; I would expect a Perl binding to support this kind of<br>thing for Perl hashes. Having said that, note that HTML5 in general has a<br>strong JS bias, since JS is the Web's main language.</blockquote>
<div><br>Sure but... <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> How can this work across language bindings? It might be a lot simpler
<br>> for everyone to only specify storage for DOM types.<br><br>It might be simpler for implementors, but I really think authors would<br>want to be able to do things like:<br><br>   globalStorage[document.domain].username = username;
<br>   globalStorage[document.domain].lastVisit = new Date();<br>   globalStorage[document.domain].game = {<br>     name: 'fred',<br>     level: 42<br>   };<br><br>...and so forth. Having to wrap stuff like that in E4X XML or (worse) DOM
<br>nodes just seems like an excessive amount of boxing.</blockquote><div><br>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: "
<span class="issue">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. 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.
<br><br>An alternative is to define storage of simple JS object trees and then force all other languages to provide a mapping to and from that. I guess that'd be acceptable.<br></span></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> <a href="http://3.4.6.1">3.4.6.1</a> <<a href="http://3.4.6.1">http://3.4.6.1</a>> "The space limits on public storage areas should<br>> not affect the limits for non-public domains, however."<br><br>
Changed that to a new suggested model based on the domain of the script<br>setting the data, not the domain of storage area. Let me know what you<br>think.</blockquote><div><br>Is the domain of the script the domain where the script was loaded from, or the domain of the document in which it runs?
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I have added text about this to the sessionStorage and globalStorage<br>sections. (Short answer: sessionStorage: only when the window is closed or
<br>when you run out of disk space; globalStorage: only when the user says so.<br>And in both cases, security concerns can trump everything and be used as<br>an excuse to delete data whenever...)</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> -- There should be some atomicity property that authors can rely on to<br>
> safely update storage under potential failures (of the UA, or the<br>> hardware, or whatever). It's probably enough to require that setItem and<br>> removeItem are atomic with respect to failure. In other words, if the UA
<br>> fails during a setItem or removeItem, then later the operation will be<br>> observed to either have succeeded normally or not happened at all (and<br>> of course the storage object will not be corrupted!).<br>
<br>Good call. Added. Let me know if what I added is enough, though.</blockquote><div><br>It looks good. That should let people build reliable storage without going the whole hog of transactions.<br></div><br>Rob</div>-- 
<br>["Therefore, my dear friends, as you have always obeyed–not only in my<br>presence, but now much more in my absence–continue to work out your<br>salvation with fear and trembling, for it is God who works in you to will
<br>and to act according to his good purpose." Philippians 2:12-13.]