- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 12 Jan 2011 10:21:00 +0000
- 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>
- Message-ID: <AANLkTin=WcrvfLU_u01tmaaiMwm=sLL5mHE_gb65suCm@mail.gmail.com>
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