The problem is that .length is basically useless without some kind of immutability guarantees.<div><br></div><div>I've thought about this more, and I'm afraid that if you start making the API cumbersome (forcing only async access) then apps are just going to use document.cookies instead of localStorage. I'd hate to see us radically change the API to support the worker case - I'd rather get rid of localStorage support from workers, or else just enforce a max time that a worker can hold the lock.</div>
<div><br><div>-atw<br><br><div class="gmail_quote">On Sun, Mar 22, 2009 at 10:46 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Sat, Mar 21, 2009 at 3:25 PM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com" target="_blank">aa@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking <jonas@sicking.cc> wrote:<br>
> The problem with synchronously grabbing the lock is that we can only<br>
> ever have one feature that uses synchronous locks, otherwise we'll<br>
> risk dead-locks.<br>
><br>
> Say that we make document.cookie behave the same way (to prevent<br>
> multi-process browsers like IE8 and chrome from having race<br>
> conditions). So that if you call document.getCookiesWithLock(callback)<br>
> we'll synchronously grab a lock and call the callback function. This<br>
> would cause two pages like the ones below to potentially deadlock:<br>
><br>
> Page 1:<br>
> getLocalStorage(function(storage) {<br>
>  document.getCookiesWithLock(function(cookieContainer) {<br>
>    storage.foo = cookieContainer.getCookie('cookieName');<br>
>  });<br>
> ]);<br>
><br>
> Page 2:<br>
> document.getCookiesWithLock(function(cookieContainer) {<br>
>  getLocalStorage(function(storage) {<br>
>    cookieContainer.setCookie('cookieName', storage.bar);<br>
>  });<br>
> });<br>
<br>
</div>Good point. Ok, I agree that an asynchronous callback makes most sense<br>
for this API.<br></blockquote><div><br></div></div></div><div>Given an async api, would it be possible to store values into localStorage at onunload time? I expect that could be a useful time to use this API.</div><div><br>
</div><div>
function onunload() {</div><div>  getLocalStorage(function(storage) {</div><div>    // Will this ever execute?</div><div>  });</div><div>}</div><div><br></div><div>Locking the storage until script completion isn't really necessary in many cases. Maybe we're over engineering this? Suppose immutability across calls was generally not guaranteed by the existing API. And we add an async getLocalStorage(callback) which does provide immutability for the duration of the callback if that is desired.</div>

<div><br></div></div>
</blockquote></div><br></div></div>