<meta charset="utf-8"><div><div class="h5">On Thu, Sep 17, 2009 at 1:32 AM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>></span> wrote:</div></div><div class="gmail_quote">

<div><div class="h5"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

On Tue, 15 Sep 2009, Jonas Sicking wrote:<br>><br>> First off, I agree that not having localStorage in workers is a big<br>> problem that we need to address.<br>><br>> If I were designing the localStorage interface today I would use the<br>

> above interface that you suggest. Grabbing localStorage can only be done<br>> asynchronously, and while you're using it, no one else can get a<br>> reference to it. This way there are no race conditions, but also no way<br>

> for anyone to have to lock.<br>><br>> So one solution is to do that in parallel to the current localStorage<br>> interface. Let's say we introduce a 'clientStorage' object. You can only<br>> get a reference to it using a 'getClientStorage' function. This function<br>

> is available both to workers and windows. The storage is separate from<br>> localStorage so no need to worry about the 'storage mutex'.<br><br>I think we should be very careful before introducing a fourth storage<br>

mechanism to make sure that whatever we introduce really is something<br>that's going to be very useful and really solve problems. I'd really<br>rather not rush into adding yet another mechanism at this point.<br>

</blockquote><div><br></div></div></div><div>Sure.  But what about the other idea Robert and Drew had (in the workers + local storage thread) about just having a WorkerLocalStorage mechanism?  Only workers would be able to access it and the interface would be exactly the same as LocalStorage.  The only difference is that the data is in a separate area (and pages/workers cannot share data).  (Though we could, in the future, add such an async interface if we wanted to allow pages to access it.)  I know the burden for implementation in WebKit is low, and I imagine (though don't know for sure) that the burden would be low in other browsers as well.</div>

</div>