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:29:28 +0000
Message-ID: <AANLkTikfF554Paq+A=2roxCpSPK=PG1TyGwcicVtAVHH@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Keean Schupke <keean@fry-it.com>, Jonas Sicking <jonas@sicking.cc>, robert@ocallahan.org, Charles Pritchard <chuck@jumis.com>, public-webapps WG <public-webapps@w3.org>
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:30:21 GMT

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