- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 12 Jan 2011 11:40:46 +0000
- 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>
- Message-ID: <AANLkTimjoq0LiGQ67-F2_p94iHaq-xAWwo2ZfT11MZfe@mail.gmail.com>
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 UTC