<div class="gmail_quote">On Mon, Oct 12, 2009 at 7:07 PM, Ian Hickson <span dir="ltr">&lt;<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>&gt;</span> wrote:<br><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; the problem here is that localStorage is a pile of global variables.<br>
&gt; we are trying to give people global variables without giving them tools<br>
&gt; to synchronize access to them.  the claim i&#39;ve heard is that developers<br>
&gt; are not savy enough to use those tools properly.  i agree that<br>
&gt; developers tend to use tools without fully understanding them.  ok, but<br>
&gt; then why are we giving them global variables?<br>
<br>
The global variables have implicit locks such that you can build the tools<br>
for explicit locking on top of them:<br>
<br>
   // run this first, in one script block<br>
   var id = localStorage[&#39;last-id&#39;] + 1;<br>
   localStorage[&#39;last-id&#39;] = id;<br>
   localStorage[&#39;email-ready-&#39; + id] = &quot;0&quot;; // &quot;begin&quot;<br>
<br>
   // these can run each in separate script blocks as desired<br>
   localStorage[&#39;email-subject-&#39; + id] = subject;<br>
   localStorage[&#39;email-from-&#39; + id] = from;<br>
   localStorage[&#39;email-to-&#39; + id] = to;<br>
   localStorage[&#39;email-body-&#39; + id] = body;<br>
<br>
   // run this last<br>
   localStorage[&#39;email-ready-&#39; + id] = &quot;1&quot;; // &quot;commit&quot;<br>
<br></blockquote><div><br></div><div>Dividing up work like this into separate SCRIPT elements to scope the</div><div>locking seems really awkward to me.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
On Thu, 24 Sep 2009, Darin Fisher wrote:<br>
&gt;<br>
&gt; The current API exposes race conditions to the web.  The implicit<br>
&gt; dropping of the storage lock is that.  In Chrome, we&#39;ll have to drop an<br>
&gt; existing lock whenever a new lock is acquired.  That can happen due to a<br>
&gt; variety of really odd cases (usually related to nested loops or nested<br>
&gt; JS execution), which will be difficult for developers to predict,<br>
&gt; especially if they are relying on third-party JS libraries.<br>
&gt;<br>
&gt; This issue seems to be discounted for reasons I do not understand.<br>
<br>
You can only lose the lock in very specific conditions. Those conditions<br>
are rarely going to interact with code that actually does storage work in<br>
a way that relies on the lock:<br>
<br>
 - changing document.domain<br>
 - history.back(), .forward(), .go(n)<br>
 - invoking a plugin<br>
 - alert(), confirm(), prompt(), print()<br>
 - showModalDialog()<br>
 - yieldForStorageUpdates()<br>
<br>
I discussed this in more detail here:<br>
<br>
   <a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html</a><br>
<br></blockquote><div><br></div><div>You are right that the conditions are specific, but I don&#39;t know that that is the</div><div>exhaustive list.  Rather than defining unlock points, I would implement implicit</div><div>
unlocking by having any nested attempt to acquire a lock cause the existing lock</div><div>to be dropped.  Nesting can happen in the cases you mention, but depending on</div><div>the UA, it may happen for other reasons too.</div>
<div><br></div><div>This combined with the fact that most people use JS libraries means that the</div><div>coder is not going to have an easy time knowing when these specific conditions</div><div>are met.  I don&#39;t think defining a set of allowed unlock points is sufficient to make</div>
<div>this API not be a minefield for users.</div><div><br></div><div>For example, a JS library might evolve to use flash for something small (like</div><div>storage or sound) that it previously didn&#39;t use when I first developed my code.</div>
<div>Voila, now my storage lock is released out from under me.</div><div><br></div><div>At this point, I&#39;m not favoring implementing the storage mutex in Chrome.  I</div><div>don&#39;t think we will have it in our initial implementation of LocalStorage.  I think</div>
<div>web developers that care will have to find another way to manage locking, like</div><div>using a Web Database transaction or coordinating with a Shared Worker.</div><div><br></div><div>Sorry to be a grump about this, but a cross-process lock that lasts until JS</div>
<div>returns is just going to slow down the web.  It is a really bad idea for that</div><div>reason.</div><div><br></div><div>-Darin</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
On Tue, 8 Sep 2009, Chris Jones wrote:<br>
&gt;<br>
&gt; Can those in the first camp explain why &quot;mutex&quot; semantics is better than<br>
&gt; &quot;transaction&quot; semantics?  And why it&#39;s desirable to have one DB spec<br>
&gt; specify &quot;transaction&quot; semantics (Web Database) and a second specify<br>
&gt; &quot;mutex&quot; semantics (localStorage)?<br>
<br>
I don&#39;t think it&#39;s desirable. It&#39;s just what we have, though an accident<br>
of history.<br>
<br>
<br>
Where we&#39;re at: localStorage can&#39;t really change. It is what it is.<br>
<br>
We have a better proposal, Web Database, but not everybody wants to<br>
implement it.<br>
<br>
To move forward, I would recommend that someone come up with a storage<br>
proposal with the following characteristics:<br>
<br>
 * All major browsers vendors are willing to implement it.<br>
 * Compatible with workers.<br>
 * Doesn&#39;t have any race conditions.<br>
 * Doesn&#39;t involve a cross-process mutex that blocks interaction.<br>
 * Stores structured data.<br>
 * Can be queried in arbitrary ways.<br>
 * Doesn&#39;t expose authors to locking primitives.<br>
<br>
Then we can replace Web Database with it and we can move on.<br>
<br>
I suggest that the right venue for this discussion would be the W3C Web<br>
Apps group, at <a href="mailto:public-webapps@w3.org">public-webapps@w3.org</a>.<br>
<br>
<br>
On Wed, 9 Sep 2009, Darin Fisher wrote:<br>
&gt;<br>
&gt; What about navigating an iframe to a reference fragment, which could<br>
&gt; trigger a scroll event?  The scrolling has to be done synchronously for<br>
&gt; compat with the web.<br>
<br>
You can only do that with same-domain pages, as far as I can tell.<br>
<br>
(Does that really have to be synchronous? Right now we don&#39;t define the<br>
&#39;scroll&#39; event anywhere. What are the semantics it needs?)<br>
<br>
<br>
On Mon, 31 Aug 2009, James Graham wrote:<br>
&gt; Quoting Ian Hickson &lt;<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>&gt;:<br>
&gt; &gt;<br>
&gt; &gt; We can&#39;t treat cookies and persistent storage differently, because<br>
&gt; &gt; otherwise we&#39;ll expose users to cookie resurrection attacks.<br>
&gt; &gt; Maintaining the user&#39;s expectations of privacy is critical.<br>
&gt;<br>
&gt; I think the paragraph under &quot;treating persistent storage as cookies&quot;<br>
&gt; should simply be removed. The remainder of that section already does an<br>
&gt; adequate job of explaining the privacy implications of persistent<br>
&gt; storage. The UI should be entirely at the discretion of the browser<br>
&gt; vendor since it involves a variety of tradeoffs, with the optimum<br>
&gt; solution depending on the anticipated user base of the browser. Placing<br>
&gt; spec requirements simply limits the abilities of browser vendors to find<br>
&gt; innovative solutions to the problem. In addition, since there is no<br>
&gt; interoperability requirement here, using RFC 2119 language seems<br>
&gt; inappropriate; especially since the justification given is rather weak<br>
&gt; (&quot;this might encourage users?&quot;) and not supported by any evidence.<br>
<br>
I think it&#39;s important to include this paragraph in a discussion of the<br>
privacy implications of these APIs. I feel like it would be irresponsible<br>
of me to not include this text, given how important this actually is.<br>
<br>
<br>
&gt; As to what browser vendors should actually _do_, it seems to me that the<br>
&gt; &quot;user&#39;s expectations of privacy&quot; is actually an illusion in this case;<br>
&gt; all the bad stuff that can be done with persistent storage can already<br>
&gt; be done using a variety of techniques. Trying to fix up this one case<br>
&gt; seems like closing the stable door after the horse has bolted. Therefore<br>
&gt; the &quot;delete local storage when you delete cookies&quot; model seems flawed,<br>
&gt; particularly as it can lead to the type of problem that Jens described<br>
&gt; above.<br>
<br>
Cookie resurrection has been a real concern on the Web. I don&#39;t think it&#39;s<br>
an illusion.<br>
<br>
<br>
&gt; On a slightly different topic, it is unclear what the relationship<br>
&gt; between the statement in section 4.3 &quot;User agents should expire data<br>
&gt; from the local storage areas only for security reasons or when requested<br>
&gt; to do so by the user&quot; and the statement in section 6.1 &quot;User agents may<br>
&gt; automatically delete stored data after a period of time.&quot; is supposed to<br>
&gt; be. Does the latter count as a security reason?<br>
<br>
I&#39;ve edited the latter text to indicate that the expiration should only be<br>
done at user option.<br>
<br>
<br>
On Fri, 2 Oct 2009, Jeremy Orlow wrote:<br>
&gt;<br>
&gt; Since my original post, I&#39;ve continued thinking about LocalStorage,<br>
&gt; structured clones, etc...and the more I&#39;ve thought about it, the more<br>
&gt; convinced I am that adding such support is a big mistake.  One way to<br>
&gt; think about it is as follows:<br>
&gt;<br>
&gt; 1)  We&#39;ve all pretty much agreed that localStorage&#39;s synchronous design<br>
&gt; was a mistake that we should be careful to not repeat.<br>
&gt;<br>
&gt; 2)  I think we can all agree that storing structured clone data makes<br>
&gt; LocalStorage more powerful and useful to developers.<br>
&gt;<br>
&gt; 3)  And I think we can all agree that developers like to use more<br>
&gt; powerful APIs.  Especially when the API is easy to use and understand<br>
&gt; (as LocalStorage is).<br>
&gt;<br>
&gt; 4)  Lock contention becomes worse as the frequency of acquires and/or<br>
&gt; the duration the lock is held increases.<br>
&gt;<br>
&gt; Although there might be some subtleties about the statements I made that<br>
&gt; people could argue with, I think all these statements are pretty<br>
&gt; fundamentally true.  Assuming so, it&#39;s not a stretch to see that 2 and 3<br>
&gt; imply that adding structured clones to local storage will lead to more<br>
&gt; use of local storage.<br>
<br>
I don&#39;t see why it would add significantly more use. Once a site is using<br>
localStorage, whether it has structured storage natively or not, they&#39;re<br>
going to store structured data in it -- e.g. using JSON, as some people<br>
have said they already are -- and so I don&#39;t think that this effectively<br>
increases the usage. It just makes it simpler for those who do use it.<br>
<br>
<br>
&gt; If use increases, then 4 implies that the storage lock is going to<br>
&gt; become a bigger problem over time.  Since we can all agree that the<br>
&gt; synchronous design of local storage is already a problem that we wish we<br>
&gt; had avoided, I just can&#39;t understand why we&#39;re happy to make it a bigger<br>
&gt; problem.<br>
&gt;<br>
&gt; Does anyone have an argument against this?<br>
<br>
I don&#39;t think it makes it a significantly bigger problem.<br>
<br>
<br>
&gt; Anyone who&#39;s going to use LocalStorage in the near to medium future will<br>
&gt; need to handle the case of LocalStorage only handling strings.  This is<br>
&gt; because structured clones supports a super-set of what can be serialized<br>
&gt; within a script, there&#39;s no way for libraries to build a transparent<br>
&gt; compatibility abstraction.  Thus, for some time, developers will either<br>
&gt; need to only use data that can be serialized (thus making structured<br>
&gt; clones only a performance optimization) or developers will need to cut<br>
&gt; off browsers that don&#39;t support structured clones.<br>
&gt;<br>
&gt; Assuming that, we&#39;re basically saying that structured clones is a<br>
&gt; feature for the long term use and health of LocalStorage.  Now I know<br>
&gt; that we can&#39;t just get rid of LocalStorage and coming up with viable<br>
&gt; alternatives will take some time, but do we really believe that we can&#39;t<br>
&gt; agree on and develop a better alternative in the mean time?<br>
<br>
I think it makes sense to allow Files to be stored today.<br>
<br>
However, I&#39;m all for a better API. So if you can get people to agree to a<br>
better API before anyone ships this one and before pages start depending<br>
on it, then maybe we can remove the structured storage feature from<br>
localStorage.<br>
<br>
<br>
&gt; I&#39;m fine with SessionStorage supporting structured clones.  I just don&#39;t<br>
&gt; think we should make LocalStorage any more powerful.  In fact, at this<br>
&gt; point, I think we should redirect all the time and effort we&#39;re putting<br>
&gt; into making LocalStorage better (including solving lock contention<br>
&gt; issues) and instead put it into creating a new API that solves these<br>
&gt; problems and that all the browser vendors can get behind.  (If you have<br>
&gt; ideas on how I can get this ball rolling, I&#39;d love to hear them!)<br>
<br>
I agree.<br>
<font color="#888888"><br>
--<br>
Ian Hickson               U+1047E                )\._.,--....,&#39;``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..&#39;--(,_..&#39;`-.;.&#39;<br>
</font></blockquote></div><br>