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

Jeremy Orlow wrote:
> I mostly agree with your assertions about the type of developer who's 
> using localStorage.  It sure would be nice if we could give developers 
> powerful APIs and keep them simple and make it possible to implement 
> them in a performant manner.  Unfortunately, I think the current design 
> cannot be changed to meet "possible to implement in a performant manner" 
> without breaking backwards compatibility.
> 

I mostly agree with that.  I like the idea of storage mutex 
conceptually, but I think it could end up hurting the Web as much as it 
helps.  For multi-event-loop UAs, |x = window.localStorage.getItem('x')| 
is an innocent-looking operation with global (browser-wide) 
consequences, and web devs will need to be mindful of those consequences.

> Part of me thinks that this API should match the WebDatabase API more. 
>  For example, you'd call a function with a callback.  That callback 
> would be given the localStorage object which it'd use to 
> do manipulations.  Etc.  But part of me like what you're suggesting 
> here.  I actually think the idea of throwing an exception whenever 
> there's a serialization problem could be very compelling, and could keep 
> the door wide open for future performance enhancements.  It's even 
> possible that javascript engines could embed elements of software 
> transactional memory in the future to eliminate the need to make such 
> calls.  That seems really exciting.
> 
 > It might also be possible to combine the 2 ideas: you call a function
 > with your callback and the callback is given a localStorage object which
 > is only valid within the callback, but an exception can be thrown when
 > there's a problem with the transaction.  Of course, the benefit to
 > explicitly starting and ending a transaction is that it can span
 > setTimeouts, event handlers, etc.  On the other hand, I wonder if the
 > cases where an app would do this and still be able to recover from a
 > transaction failure would be limited.
 >

I would be satisfied with a callback API, even an async one.  If we were 
to go forward with transactional localStorage, I think the main API 
design decision would be whether or not to "hide" transactions from 
authors.  Obviously hiding them would be desirable, but unlike 
WebDatabase, localStorage can't easily import SQL semantics.  If we were 
to hide them,  I think we should offer a StorageTransaction object 
describing the operations to be performed on the DB, and offer the 
function localStorage.executeTransaction(txnObject).  In this way we 
could avoid the side-effecty problems of generic scripts accessing 
localStorage.

But personally, I prefer exposed transactions.  A transaction might 
contain data dependencies --- for example, x = getItem('x'), x += 1, 
setItem('x', x).  It seems to me very hard to capture this in an API 
that hides transactions from the user while at the same time not turning 
into a scripting language unto itself (or providing a strongly 
restricted scripting environment in a "transaction callback").

> Another thing we might want to consider is making transactions optional. 
>  This would satisfy group 1 and 2, but would put the group 3 you 
> mentioned at more risk.  In other words, not calling beginTransaction 
> would not be fatal.  It would just mean localStorage works as currently 
> spec'ed.  But, doing it within a transaction (be it a callback or within 
> ___Transaction calls) would give you additional guarantees.
> 

I would really prefer to not do that.  Can any web devs using 
localStorage comment on how they detect whether browsers support that 
feature?  If the test is something like 
|window.hasProperty('localStorage')|, then I would prefer to make this 
return |false| until |window.beginTransaction| was accessed.

Cheers,
Chris

Received on Friday, 4 September 2009 13:24:15 UTC