[whatwg] localStorage + worker processes

On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson <atwilson at google.com> wrote:

> The problem is that .length is basically useless without some kind of
> immutability guarantees.


Understood, and when you need that guarantee it would be available via the
getLocalStorage(callback) API.


>
> I've thought about this more, and I'm afraid that if you start making the
> API cumbersome (forcing only async access) then apps are just going to use
> document.cookies instead of localStorage. I'd hate to see us radically
> change the API to support the worker case - I'd rather get rid of
> localStorage support from workers, or else just enforce a max time that a
> worker can hold the lock.
>
> -atw
>
>
> On Sun, Mar 22, 2009 at 10:46 AM, Michael Nordman <michaeln at google.com>wrote:
>
>>
>>
>> On Sat, Mar 21, 2009 at 3:25 PM, Aaron Boodman <aa at google.com> wrote:
>>
>>> On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>> > The problem with synchronously grabbing the lock is that we can only
>>> > ever have one feature that uses synchronous locks, otherwise we'll
>>> > risk dead-locks.
>>> >
>>> > Say that we make document.cookie behave the same way (to prevent
>>> > multi-process browsers like IE8 and chrome from having race
>>> > conditions). So that if you call document.getCookiesWithLock(callback)
>>> > we'll synchronously grab a lock and call the callback function. This
>>> > would cause two pages like the ones below to potentially deadlock:
>>> >
>>> > Page 1:
>>> > getLocalStorage(function(storage) {
>>> >  document.getCookiesWithLock(function(cookieContainer) {
>>> >    storage.foo = cookieContainer.getCookie('cookieName');
>>> >  });
>>> > ]);
>>> >
>>> > Page 2:
>>> > document.getCookiesWithLock(function(cookieContainer) {
>>> >  getLocalStorage(function(storage) {
>>> >    cookieContainer.setCookie('cookieName', storage.bar);
>>> >  });
>>> > });
>>>
>>> Good point. Ok, I agree that an asynchronous callback makes most sense
>>> for this API.
>>>
>>
>> Given an async api, would it be possible to store values into localStorage
>> at onunload time? I expect that could be a useful time to use this API.
>>
>>  function onunload() {
>>   getLocalStorage(function(storage) {
>>     // Will this ever execute?
>>   });
>> }
>>
>> Locking the storage until script completion isn't really necessary in many
>> cases. Maybe we're over engineering this? Suppose immutability across calls
>> was generally not guaranteed by the existing API. And we add an async
>> getLocalStorage(callback) which does provide immutability for the duration
>> of the callback if that is desired.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090322/f055aad4/attachment-0001.htm>

Received on Sunday, 22 March 2009 11:30:56 UTC