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

Robert O'Callahan wrote:
> On Sun, Sep 6, 2009 at 4:55 AM, Chris Jones <cjones at mozilla.com 
> <mailto:cjones at mozilla.com>> wrote:
> 
>     I mean prevent the UA from affecting a script's execution.  The
>     cases I've thought of so far where we will probably have to break
>     storage-mutex semantics are
> 
>      * clear private data
> 
>      * close tab
>      * quit UA
> 
> 
> I think these could appear to complete immediately while doing their 
> work asynchronously in the background, given the assumption that content 
> script execution time is bounded (if it takes "too long" we enforce the 
> assumption using the slow-script timeout).
> 
>      * "slow script" timeout
>      * store-to-disk failure
>      * crash
> 
> 
> In HTML5 we generally take the approach that if a UA is unable to 
> satisfy spec semantics due to resource limits or other problems in the 
> environment, then it's OK to deviate from the spec. Applying that 
> principle here, we would not need to provide database consistency in the 
> presence of these failures.
> 

I don't like the idea of the spec creating an illusion that's impossible 
for browser vendors to maintain.

>     I'm beginning to think that this discussion is more about DB
>     consistency than multi-event-loop UAs.  I think it's telling that
>     all of the cases I listed above could arise in single-process Gecko
>     except "clear private data" (and maybe "close tab", not sure).
> 
>  
> Currently in Gecko "clear private data", "close tab" and "quit" would 
> all wait for running scripts to complete. But indeed, the consistency 
> you want isn't provided by any browser today if the app encounters 
> resource limits or hardware failures. Storing a single key-value pair 
> should be atomic in the case of failure, so apps have to roll-your-own 
> consistency and recovery using that.
> 

"Force quit" will interrupt scripts.

Desktop apps have to worry about DB consistency, and DBs for those 
provide transactional consistency guarantees.  It seems undesirable to 
deny them to web apps using localStorage, especially since localStorage 
seems more author-friendly than Web Database.  (Undesirable excepting 
compatibility with existing localStorage impls.)  This is a rhetorical 
point not necessarily directed at you personally, since I think we're 
pretty much on the same page.

Cheers,
Chris

Received on Saturday, 5 September 2009 15:00:34 UTC