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

Robert O'Callahan wrote:
> On Sat, Sep 5, 2009 at 10:22 AM, Chris Jones <cjones at mozilla.com 
> <mailto:cjones at mozilla.com>> wrote:
> 
>     And if the intention is to make scripts appear to run atomically,
>     then I think there are better ways to specify that than storage mutex.
> 
> 
> That sounds good, how?
> 

My OP is my weak attempt at getting closer to this.  "Weak" because it's 
still rather imperative rather than declarative, but that's in the style 
of the rest of HTML5.  If I could start from scratch, I would define 
run-to-completion semantics (which I love, BTW) in terms of global state 
visible to script and a happens-before relation on events that might 
change that state.  But it's not clear to me that a 
Java-memory-model-type spec would be better for the web than a spec like 
HTML5's.

>     My problem with storage mutex boils down to the fact that by the
>     letter of the spec, a script can lock out the UA indefinitely by
>     just reading a cookie.
> 
> 
> What do you mean "lock out the UA"?
>  

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
   * "slow script" timeout
   * store-to-disk failure
   * crash

For those cases, IMHO transactional semantics is better because it gives 
scripts the guarantee that operations on localStorage are atomic.  In 
the "secret-storage-mutex world," if you agree that the cases above 
imply that the UA will have to interrupt scripts, then it's possible for 
scripts to make changes to localStorage that are only partially applied, 
going by the letter of the storage mutex spec.  I think that for sites 
that would care (e.g. gmail), partially-applied changes are a bad thing. 
  And as I argued in the OP, I think localStorage should be designed 
only with sites like gmail in mind.

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).

> 
>     Transactional semantics seems to be a better abstraction, and an
>     ancillary benefit is that it's much easier to implement to boot.
>      Though even if it were harder to implement, I would still argue for it.
> 
>  
> I agree with you. However, there is still the compatibility issue. (Some 
> people may also argue that what we currently have is simpler for authors 
> than any explicit transactional API --- personally I'm unsure if that 
> matters.)
> 

API breakage is a problem, but does my proposal to only sort of break 
compatibility through pretending not to offer window.localStorage until 
window.beginTransaction is accessed not satisfy?

Cheers,
Chris

Received on Saturday, 5 September 2009 09:55:16 UTC