On Sat, Sep 12, 2009 at 1:20 AM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">aa@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Fri, Sep 11, 2009 at 9:03 AM, Mike Shaver <<a href="mailto:mike.shaver@gmail.com">mike.shaver@gmail.com</a>> wrote:<br>
> Aaron,<br>
><br>
> You're right, my recollection is quite incorrect.  My apologies for<br>
> unfairly describing the origin of the proposal.<br>
<br>
</div>I forgive you :).<br>
<br>
In fact, the many design changes to the database API were made<br>
precisely because they made it more webby, within the constraints of<br>
being SQL-based. As on example, the fully asynchronous API was done to<br>
avoid blocking the UI thead, something that is important for web<br>
browsers. All of this played out on the WhatWG mailing list over<br>
several months with input from many vendors, but admittedly, mostly<br>
Google and Apple (not for want of other input -- just because we<br>
seemed to be the two that most wanted this feature).<br>
<div class="im"><br>
> Do you agree with Jeremy that Database is too far along in terms of<br>
> deployment to have significant changes made to it?  Given that we're<br>
> still hashing our major philosophical elements with respect to<br>
> transactionality and locking in parts of HTML5, I can imagine it being<br>
> quite desirable to make Database conform to whatever model we settle<br>
> on.  "Does the localStorage mutex plus onbeforeunload plus Database<br>
> transaction collision equal deadlock?", etc.<br>
<br>
</div>I don't think that is what Jeremy was saying (emphasis mine):<br>
<div class="im"><br>
On Fri, Sep 11, 2009 at 1:26 AM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> In theory.  In practice, once a vendor has shipped something, it's somewhat<br>
> sacred.  Once multiple have, it's even more so.  ****This is somewhat<br>
> unfortunate, in my opinion, since very few people are using localStorage or<br>
> DB yet****, but it's now very difficult to correct even major problems in the<br>
> spec.<br>
<br>
</div>Picking another message from very early in the other thread that<br>
spawned this one:<br>
<br>
On Tue, Sep 8, 2009 at 1:08 AM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> First of all, I'm not sure I agree that we're at the point where<br>
> breaking compatibility is impossible.  It really doesn't seem like it's<br>
> terribly widely used, and what's implemented is based on an early draft of<br>
> the spec.  Yes, I agree that it's really unfortunate we didn't iron these<br>
> problems out better before everyone implemented it, but if LocalStorage<br>
> changed today, it definitely wouldn't break the web.  (Of course, it's<br>
> possible that we would be breaking the web by the time the next gen of the<br>
> major browsers ship.....it's hard to know for sure.)<br>
<br>
Throughout, he has reiterated his belief that we are *not* too far<br>
along to change the design.<br></blockquote><div><br></div><div>Exactly.  I think there are some major design flaws and that we should correct them.  It's others who are saying the current designs, though majorly flawed, are too entrenched to change.</div>

</div>