- From: Glenn Maynard <glenn@zewt.org>
- Date: Thu, 6 Jan 2011 23:14:33 -0500
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Felix Halim <felix.halim@gmail.com>, Jeremy Orlow <jorlow@chromium.org>, public-webapps WG <public-webapps@w3.org>
On Thu, Jan 6, 2011 at 10:55 PM, Jonas Sicking <jonas@sicking.cc> wrote: > Note that the above intentionally doesn't use localStorage! But rather > a different Storage object which can only be accessed asynchronously > and which doesn't overlap with localStorage. > > So long as you only allow asynchronous access the implementation can > ensure that a worker and the main thread doesn't have access to the > storage at the same time. Then it is safe to allow everyone to modify > the storage area. I'd recommend that the underlying Storage objects that this function (or functions, for each Storage object) returns should in fact be the same object (or a thin wrapper, to implement disabling the object after the callback returns). For example, getBetterLocalStorage should use the same underlying storage as localStorage. If a site wants to guarantee that no asynchronous changes are made, even on browsers that don't implement the synchronous lock (the lock that's currently specced), it would need to limit itself to the async API to access these objects. On a strictly by-spec browser, mixing both APIs would be safe; the async callback would never be called while the storage mutex is held. This seems much more straightforward to users than having separate "sync" and "async" storage, and it's much easier to debug than having a Storage object only accessible from a callback; I regularly manipulate localStorage from the console. I'm assuming that if an API like this was adopted, the synchronous lock for the current localStorage API would remain in the spec. -- Glenn Maynard
Received on Friday, 7 January 2011 04:15:05 UTC