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

Re: [chromium-html5] LocalStorage inside Worker

From: Felix Halim <felix.halim@gmail.com>
Date: Tue, 11 Jan 2011 12:26:17 +0700
Message-ID: <AANLkTimxHWGJBrgFB-rxLUTCnxpmJ_ek6xpmKzpqgaUs@mail.gmail.com>
To: robert@ocallahan.org
Cc: Keean Schupke <keean@fry-it.com>, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps WG <public-webapps@w3.org>
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.

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.

So what's the justification of making localStorage thread safe?

Felix Halim

On Tue, Jan 11, 2011 at 6:42 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> STM is not a panacea. Read
> http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx
> if you haven't already.
>
> In Haskell, where you have powerful control over effects, it may work well,
> but Javascript isn't anything like that.
>
> Rob
> --
> "Now the Bereans were of more noble character than the Thessalonians, for
> they received the message with great eagerness and examined the Scriptures
> every day to see if what Paul said was true." [Acts 17:11]
>
Received on Tuesday, 11 January 2011 05:26:50 GMT

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