[whatwg] Application defined "locks"

[Aaron Boodman]

On Fri, Sep 11, 2009 at 9:03 AM, Mike Shaver <mike.shaver at gmail.com> wrote:
> Aaron,
>
> You're right, my recollection is quite incorrect.  My apologies for
> unfairly describing the origin of the proposal.

I forgive you :).

In fact, the many design changes to the database API were made
precisely because they made it more webby, within the constraints of
being SQL-based. As on example, the fully asynchronous API was done to
avoid blocking the UI thead, something that is important for web
browsers. All of this played out on the WhatWG mailing list over
several months with input from many vendors, but admittedly, mostly
Google and Apple (not for want of other input -- just because we
seemed to be the two that most wanted this feature).

> Do you agree with Jeremy that Database is too far along in terms of
> deployment to have significant changes made to it?  Given that we're
> still hashing our major philosophical elements with respect to
> transactionality and locking in parts of HTML5, I can imagine it being
> quite desirable to make Database conform to whatever model we settle
> on.  "Does the localStorage mutex plus onbeforeunload plus Database
> transaction collision equal deadlock?", etc.

I don't think that is what Jeremy was saying (emphasis mine):

On Fri, Sep 11, 2009 at 1:26 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> In theory.  In practice, once a vendor has shipped something, it's somewhat
> sacred.  Once multiple have, it's even more so.  ****This is somewhat
> unfortunate, in my opinion, since very few people are using localStorage or
> DB yet****, but it's now very difficult to correct even major problems in the
> spec.

Picking another message from very early in the other thread that
spawned this one:

On Tue, Sep 8, 2009 at 1:08 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> First of all, I'm not sure I agree that we're at the point where
> breaking compatibility is impossible.  It really doesn't seem like it's
> terribly widely used, and what's implemented is based on an early draft of
> the spec.  Yes, I agree that it's really unfortunate we didn't iron these
> problems out better before everyone implemented it, but if LocalStorage
> changed today, it definitely wouldn't break the web.  (Of course, it's
> possible that we would be breaking the web by the time the next gen of the
> major browsers ship.....it's hard to know for sure.)

Throughout, he has reiterated his belief that we are *not* too far
along to change the design.

I think this thread has gotten long enough and involves enough people
that every possible position has already been laid out, and we
continue only out of brownian motion.

- a