On Fri, Apr 3, 2009 at 2:18 AM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@opera.com">annevk@opera.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Fri, 03 Apr 2009 06:26:43 +0200, Robert O'Callahan <<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mozilla could probably get behind that, but I don't know who else is willing to bite the bullet.<br>
</blockquote>
<br></div>
The problem already exists for document.cookie, no? And the current API is by far the most convenient the use.<font color="#888888"></font></blockquote><div><br>If I understood the discussion correctly, the spec for document.cookie never stated anything about it being immutable while a script is running. People are now talking about specifying this, but there's been push back. Also, there's no way to guarantee serializability for the network traffic portion so I'm guessing (hoping!) that this wouldn't be required in the JavaScript side, even if it went through.<br>
<br>localStorage, on the other hand, does have language in the draft spec stating that changes to localStorage must be serialized as if only one event loop is running at a time. That's the problem. In other words, the strictness of the concurrency control for localStorage is what makes this different from document.cookie.<br>
<br><br>As for convenience:<br><br>The spec is written in such a way that you can't have more that one event loop per browser window/worker, and everything is essentially tied to this one event loop. In other words, each window/worker can't run on more than one CPU core at a time. Thus, the only way for a web application to scale in todays world is going to be through additional windows and/or workers.<br>
<br>I agree that the current API is quite convenient, but it worries me a great deal that it's synchronous. Now that navigator.unlockStorage() has been added to the spec and you can't access localStorage from workers, I'm less worried. But I still feel like we're going to regret this in the next couple years and/or people will simply avoid localStorage.<br>
<br>J<br></div></div>