[whatwg] localStorage, the storage mutex, document.domain, and workers

[Michael Nordman]

These two statements are true...
* "We can't change the API"
* It is seriously flawed
... and therein lies the problem.

I'm sad to have to say it... but I hope this withers and dies an early
death. Putting this in the web platform for perpetuity is a mistake. I don't
support the adoption of this into the platform.

Time to go read the SimpleDatabase proposal.

> On Wed, 9 Sep 2009, Darin Fisher wrote:
>> By the way, you can already pretty much create my acquireLock /
>> releaseLock API on top of SharedWorkers today, but in a slightly
>> crappier way.
>
> How? Since the API is completely async, you can't make a spinlock.

You must not have read Darin's proposal. It wasn't a 'lock' at all. It's a
completely async, well-factored primitive.
  void acqureFlag('name', callback);   // returns immediately in all cases
  void releaseFlag('name');  // returns immediately in all cases
The callback is called upon 'flag' acquisition. Its all yours until you call
release. Completely async. I think its self-evident that this can be
composed with a SharedWorker.

Darin's was an example of a good proposal... simple on all dimensions, yet
powerful and broadly applicable... what is not to like? Marry the 'flag'
with a unlocked storage repository and viola, you have something... the
whole is greater than the sum of the parts.

Another lesson to be learned from the LocalStorage debacle is to decompose
things, hashmaps+(implicit)locks+events... it slices and dices (and there's
more)... it was a bad idea to jumble all that together... individually,
minus the implicit, those would make for nice features.

Also, regarding "we can't change the API"... well it did get changed... the
application of additional implicit locking semantics to IE's API... that is
a material change.


On Thu, Sep 17, 2009 at 5:13 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Sep 17, 2009 at 8:32 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>> LESSONS LEARNT
>>
>> If we ever define a new API that needs a lock of some kind, the way to do
>> it is to use a callback, so that the UA can wait for the lock
>> asynchronously, and then run the callback once it has it. (This is what
>> the Web Database spec does, for instance.)
>>
>
> When we add more of these features, I think we will need a way to acquire
> multiple locks simultaneously before running a callback. (So if we had
> localStorage.runTransaction(function(storage) { ... }) and
> otherLockingThing.runTransaction(function(thing) { ... }), we could also
> have, for example, window.runTransaction(localStorage, otherLockingThing,
> function(storage, thing) { ... }).) So it may be worth thinking about what
> that API should be and what we will need to add to each feature spec to
> support it.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090918/76bbbd40/attachment-0001.htm>