[whatwg] localStorage, the storage mutex, document.domain, and workers

[Jeremy Orlow]

On Thu, Sep 17, 2009 at 1:32 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 15 Sep 2009, Jonas Sicking wrote:
> >
> > First off, I agree that not having localStorage in workers is a big
> > problem that we need to address.
> >
> > If I were designing the localStorage interface today I would use the
> > above interface that you suggest. Grabbing localStorage can only be done
> > asynchronously, and while you're using it, no one else can get a
> > reference to it. This way there are no race conditions, but also no way
> > for anyone to have to lock.
> >
> > So one solution is to do that in parallel to the current localStorage
> > interface. Let's say we introduce a 'clientStorage' object. You can only
> > get a reference to it using a 'getClientStorage' function. This function
> > is available both to workers and windows. The storage is separate from
> > localStorage so no need to worry about the 'storage mutex'.
>
> I think we should be very careful before introducing a fourth storage
> mechanism to make sure that whatever we introduce really is something
> that's going to be very useful and really solve problems. I'd really
> rather not rush into adding yet another mechanism at this point.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090917/a49a3245/attachment-0001.htm>