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

Re: [chromium-html5] LocalStorage inside Worker

From: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 12 Jan 2011 10:21:00 +0000
Message-ID: <AANLkTin=WcrvfLU_u01tmaaiMwm=sLL5mHE_gb65suCm@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Keean Schupke <keean@fry-it.com>, robert@ocallahan.org, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, public-webapps WG <public-webapps@w3.org>
On Tue, Jan 11, 2011 at 8:58 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> With localStorage being the way it is, I personally don't think we can
> ever allow localStorage access in workers.
>
> However I do think we can and should provide access to a separate
> storage area (or several named storage areas) which can only be
> accessed from callbacks.


So basically you want to create yet another storage API?  Didn't we decide a
while ago this was a bad idea?

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...


> On the main thread those callbacks would be
> asynchronous. In workers those callbacks can be either synchronous or
> asynchronous. Here is the API I'm proposing:
>
> getNamedStorage(in DOMString name, in Function callback);
> getNamedStorageSync(in DOMString name, in Function callback);
>
> The latter is only available in workers. The former is available in
> both workers and in windows. When the callback is called it's given a
> reference to the Storage object which has the exact same API as
> localStorage does.
>
> Also, you're not allowed to nest getNamedStorageSync and/or
> IDBDatabaseSync.transaction calls.
>
> This has the added advantage that it's much more implementable without
> threading hazards than localStorage already is.
>
> / Jonas
>
> On Tue, Jan 11, 2011 at 6:40 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > So what's the plan for localStorage in workers?
> > J
> >
> > On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke <keean@fry-it.com> wrote:
> >>
> >> I think I already came to the same conclusion... JavaScript has no
> control
> >> over effects, which devalues STM. In the absence of effect control,
> apparent
> >> serialisation (of transactions) is the best you can do.
> >> What we need is a purely functional JavaScript, it makes threading so
> much
> >> easier ;-)
> >>
> >> Cheers,
> >> Keean.
> >>
> >> On 10 January 2011 23:42, 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 Wednesday, 12 January 2011 10:21:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:15 UTC