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

Re: [chromium-html5] LocalStorage inside Worker

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 12 Jan 2011 06:14:20 -0500
Message-ID: <AANLkTikgqFTdsmoZCB6Hc-HcOXK5Ha6LuBgJHG9MAeaH@mail.gmail.com>
To: Keean Schupke <keean@fry-it.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, 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 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.

-- 
Glenn Maynard
Received on Wednesday, 12 January 2011 11:14:53 GMT

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