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
