[whatwg] LocalStorage in workers

On Wed, Sep 16, 2009 at 4:05 PM, Michael Nordman <michaeln at google.com>wrote:

>
>
> On Wed, Sep 16, 2009 at 3:30 PM, Jeremy Orlow <jorlow at chromium.org> 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.
>>>
>>
>> Ah yes.  That is also an option.
>>
>> And, now that I think about it (combined with Jonas' last point) I think
>> it might be the best option since it has a very low implementation cost, it
>> keeps the very simple API, and solves the primary problem of not blocking
>> pages' event loops.
>>
>
> But it fails to solve the problem of a providing a shared storage
> repository for the applications use, which at least to me is the real
> primary goal.
>

Is it?  Can you provide some use cases?  :-)

As I stated, my conversations with developers led me to believe having
access to storage within workers is most important and that having shared
memory between pages and workers would make things easier on some of them.
 In other words, from my talks, it's a secondary goal.


On Wed, Sep 16, 2009 at 3:57 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Wed, Sep 16, 2009 at 3:36 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> > 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?
>

Well, doing just a sync interface is "MUCH simpler", but I suppose there's
no reason not to add both to the spec.  To be clear, though, adding the sync
interface to workers would be a much higher priority for me than the async
interface.  Enough so that there's a chance we'd ship a version of Chrome
that did not yet implement the async interface.  That seems OK to me,
though.


> 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?
>

The use cases all revolve around having a backend in a worker that handles
offline and/or caching.  It could either feed its data to the page via
messages or shared memory.  The former requires at least worker-only and the
latter requires storage shared between the worker and the page.  The latter
is technically an optimization, but I agree that it's a fairly major one.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090916/56d5ee66/attachment.htm>

Received on Wednesday, 16 September 2009 16:17:38 UTC