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:37:30 UTC