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: Tue, 11 Jan 2011 01:02:34 -0500
Message-ID: <AANLkTikc-n9Hz-eknkacKOcKWVb7CAQE3YkNTOpnCm3p@mail.gmail.com>
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 GMT

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