[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

[Maciej Stachowiak]

On Sep 8, 2009, at 4:10 PM, Jonas Sicking wrote:

> On Tue, Sep 8, 2009 at 4:00 PM, Maciej Stachowiak<mjs at apple.com>  
> wrote:
>>
>> On Sep 8, 2009, at 1:35 AM, Jonas Sicking wrote:
>>
>>>
>>> I think Firefox would be willing to break compat. The question is if
>>> microsoft is. Which we need to ask them.
>>
>> We would be very hesitant to break LocalStorage API compatibility for
>> Safari, at least without some demonstration that the level of  real- 
>> world
>> breakage is low (including for mobile-specific/iPhone-specific  
>> sites).
>
> Even if that means that you'll for all future will need to use a
> per-domain mutex protecting localStorage? And even possibly a global
> mutex as currently specified?

I don't think telling this story to users or developers will make them  
satisfied with the breakage, so the "even if" is not very relevant.

I think there are ways to solve the problem without completely  
breaking compatibility. For example:

- Keep the current LocalStorage API, but make it give no concurrency  
guarantees whatsoever (only single key/value accesses are guaranteed  
atomic).
- Add a simple optional transactional model for aware authors who want  
better consistency guarantees.

This might not meaningfully break existing content, unlike proposals  
for effectively mandatory new API calls. Particularly since IE doesn't  
have any kind of storage mutex.

Yet another possibility is to keep a per-domain mutex, also offer a  
transactional API, and accept that careless authors may indefinitely  
lock up the UI for all pages in their domain (up to the slow script  
execution limit) if they code poorly, but in exchange won't have  
unexpected race conditions with themselves.

Regards,
Maciej