[whatwg] LocalStorage in workers

[Jonas Sicking]

On Wed, Sep 16, 2009 at 3:36 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> On Wed, Sep 16, 2009 at 3:32 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> On Wed, Sep 16, 2009 at 3:21 PM, Robert O'Callahan <robert at ocallahan.org>
>> wrote:
>> > On Thu, Sep 17, 2009 at 9:56 AM, Jeremy Orlow <jorlow at chromium.org>
>> > wrote:
>> >>
>> >> 1) Create a LocalStorage like API that can only be accessed in an async
>> >> way via pages (kind of like WebDatabase).
>> >> 2) Remove any
>> >> atomicity/consistency guarantees from synchronous LocalStorage access
>> >> within
>> >> pages (like IE8 currently does) and add an async interface for when
>> >> pages do
>> >> need atomicity/consistency.
>> >> 3) Come up with a completely different storage API that all the browser
>> >> vendors are willing to implement that only allows Async access from
>> >> within
>> >> pages.  WebSimpleDatabase might be a good starting point for this.
>> >
>> > 4) Create WorkerStorage so that shared workers have exclusive,
>> > synchronous
>> > access to their own persistent storage via an API compatible with
>> > LocalStorage.
>>
>> I think some of the use cases require that code running in Window
>> objects can access the same storage area though. Consider for example
>> an email web app that uses a WorkerStorage area for to store email
>> data locally (for performance and for offline support), and then uses
>> a worker to synchronize that with the server.
>>
>> Here the code running in the Window wants to access the storage in
>> order to render the emails in the page, and the worker wants to access
>> it to synchronize with the server.
>>
>> See my email earlier in this thread. If we change the name from
>> 'clientStorage' to 'workerStorage', while still allowing the main
>> window to asynchronously get a reference to the storage, then I think
>> that about matches what you're proposing (and what item 1 is
>> proposing).
>
> Code wise, what Robert suggested is MUCH simpler.  Almost for free in
> WebKit.  Creating an asynchronous access method and exposing this in the
> page is much more complex.  It also defeats the main purpose of LocalStorage
> (which is to be a simple, light weight way to store data).

The only difference between Roberts and my suggestion is that I'm also
adding a asynch accessor in the window. That doesn't seem to make it
"MUCH simpler", or am I missing something?

I do agree that some of the additional optional
multiple-differently-named storage area does add additional
complexity, and maybe we should defer that to something like the
WebSimpleStorage spec.

> I certainly agree that having some shared memory format between workers and
> pages would be good, and there's some use cases which would
> certainly benefit, but most of the developers I've talked to so far were
> mostly concerned about having _some_ form of storage and the shared memory
> aspects were more nice to have.

What would the specifics of a worker-only storage be? Can multiple
different workers access it? (In which case they need to be protected
by a mutex). Is there one storage per worker URL? Or do all workers
from a particular domain share the same workerStorage?

I'm also wondering what the use-cases for a worker-only storage is?

/ Jonas