<br><br><div class="gmail_quote">On Sun, Mar 22, 2009 at 11:53 AM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">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 class="im">On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson <<a href="mailto:atwilson@google.com">atwilson@google.com</a>> wrote:<br>
</div><div class="im">> I've thought about this more, and I'm afraid that if you start making the<br>
> API cumbersome (forcing only async access) then apps are just going to use<br>
> document.cookies instead of localStorage. I'd hate to see us radically<br>
> change the API to support the worker case - I'd rather get rid of<br>
> localStorage support from workers, or else just enforce a max time that a<br>
> worker can hold the lock.<br>
<br>
</div>I don't believe that. Adding one async callback is no inconvenience<br>
compared to the sad farce that is the document.cookie "API". Also,<br>
localstorage has many benefits including structured storage and not<br>
getting sent to the server in every request.</blockquote><div><br></div><div>I don't see how denying workers solves the problem. In a multi-threaded browser, this has to be resolved reasonably even in the absence of workers. </div>
<div><br></div><div><br></div></div>