- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 11 Jan 2011 01:02:34 -0500
- To: Felix Halim <felix.halim@gmail.com>
- Cc: robert@ocallahan.org, Keean Schupke <keean@fry-it.com>, Charles Pritchard <chuck@jumis.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps WG <public-webapps@w3.org>
On Tue, Jan 11, 2011 at 12:26 AM, Felix Halim <felix.halim@gmail.com> wrote: > Looking through all these complexities, I'm wondering why do we need > to make localStorage "thread safe" in the first place? I mean, we can > always switch to IndexedDB if we want thread safe storage. I don't think Jonas's suggestion is complex. (It's certainly less convenient, but I think that's bearable.) > localStorage should focus on simplicity and performance and ignore > thread safety since, IMHO, localStorage is used for UI purposes or > preferences settings (not data itself). If you open two tab, you > change settings in one tab, you can just refresh the other tab and I > believe both of them will have the same UI state again. It's used for data storage, too, particularly since it's widely available in production; IndexedDB is not. > So what's the justification of making localStorage thread safe? I think the general goal is simply to have as few side-effects of external things happening while Javascript code is running as possible. Wherever you eliminate that, you eliminate potential race conditions. -- Glenn Maynard
Received on Tuesday, 11 January 2011 06:03:07 UTC