W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [chromium-html5] LocalStorage inside Worker

From: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 12 Jan 2011 11:40:46 +0000
Message-ID: <AANLkTimjoq0LiGQ67-F2_p94iHaq-xAWwo2ZfT11MZfe@mail.gmail.com>
To: Keean Schupke <keean@fry-it.com>
Cc: Glenn Maynard <glenn@zewt.org>, Jonas Sicking <jonas@sicking.cc>, robert@ocallahan.org, Charles Pritchard <chuck@jumis.com>, public-webapps WG <public-webapps@w3.org>
Agreed.

There's lots of stuff in the web platform that you basically just shouldn't
use/do but that we have to leave in.  In my opinion, localStorage is just
yet another one.  (And yes, this is coming from the person who implemented
it in Chromium. :-)

J

On Wed, Jan 12, 2011 at 11:36 AM, Keean Schupke <keean@fry-it.com> wrote:

> So, it may be acceptable to say you can't use localStorage from a worker,
> use IndexedDB instead. But is it acceptable to leave localStorage broken
> with multiple tabs/windows.  As the spec says there should be a global lock,
> that seems to be an implementation problem though.
>
>
> Cheers,
> Keean.
>
>
> On 12 January 2011 11:29, Jeremy Orlow <jorlow@chromium.org> wrote:
>
>> On Wed, Jan 12, 2011 at 11:14 AM, Glenn Maynard <glenn@zewt.org> wrote:
>>
>>> On Wed, Jan 12, 2011 at 6:00 AM, Keean Schupke <keean@fry-it.com> wrote:
>>> > IMHO, if the global lock on localStorage implemented, then I think it
>>> is
>>> > acceptable to say localStorage may have poor performance with multiple
>>> > windows/tabs open. If you want better then use IndexedDB.
>>>
>>> Performance isn't the problem.  The problems, as I understand them, are:
>>>
>>> 1: the global lock is simply not being implemented; it's too hard to
>>> implement this sort of locking from within a running UI thread
>>> properly, and
>>> 2: unlike scripts in the main thread, a worker thread may not return
>>> to caller regularly; that's when the storage mutex is unlocked, which
>>> means there's no proepr way to unlock the storage mutex from a thread.
>>>
>>> The callback API addresses both of these problems.
>>>
>>> On 12 January 2011 10:21, Jeremy Orlow <jorlow@chromium.org> wrote:
>>> > Why not just use a small library (like lawnchair) on top of IndexedDB
>>> > instead?  This doesn't seem like it's worth the surface area at all...
>>>
>>> This sounds more like an argument for deprecating the entire Storage API.
>>>
>>
>> It is, but the thing with the web platform is that once you add something
>> you can pretty much never remove it.
>>
>> But I'll be doing everything in my power to push people away from
>> LocalStorage once IndexedDB is a bit more mature.
>>
>> J
>>
>
>
Received on Wednesday, 12 January 2011 11:41:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT