<div class="gmail_quote">On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">aa@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman<<a href="mailto:aa@google.com">aa@google.com</a>> wrote:<br>
> I see.<br>
><br>
> So you are suggesting the localStorage could have zero concurrency<br>
> guarantees and it is simply up to the developer to arrange things<br>
> themselves using this new primitive.<br>
><br>
> That is an interesting idea. You're right that it overlaps with the<br>
> ideas that inspired shared workers, and the global script proposal.<br>
<br>
</div>Ok, after thinking about this for a day, I'm going to say I think this<br>
is a very cool idea, and a worthwhile addition, but I don't think it<br>
should substitute for having the local storage API work correctly by<br>
default.<br>
<br>
The web platform is supposed to work for developers of all experience<br>
levels. If we make local storage have no concurrency guarantees, it<br>
will seem like it works in the overwhelming majority of cases. It will<br>
work in all SELUAs, and it will only NOT work in MELUAs in cases that<br>
are basically impossible to test, let alone see during development.<br>
<br>
We have tried hard with the design of the web platform to avoid these<br>
sort of untestable non-deterministic scenarios, and I think it is to<br>
the overall value of the platform to continue this.<br>
<br>
Therefore, my position continues to be that to access local storage,<br>
there should be an API that asynchronously acquires exclusive access<br>
to storage.<br>
<font color="#888888"><br>
- a<br>
</font></blockquote></div><br><div><br></div><div>Yeah, if you had to call an API that asynchronously acquires exclusive access</div><div>to storage, then I believe that would nicely address most of the issues.  It is the</div>
<div>solution we have for database transactions.</div><div><br></div><div>I say "most" because I'm not sure that it eliminates the need to drop the storage</div><div>mutex in the showModalDialog case.</div><div>
<br></div><div>If I call showModalDialog from within a database transaction, and then showModalDialog</div><div>tries to create another database transaction, should I expect that the transaction</div><div>can be started within the nested run loop of the modal dialog?  If not, then it may cause</div>
<div>the app to get confused and never allow the dialog to be closed (e.g., perhaps the close</div><div>action is predicated on a database query.)</div><div><br></div><div>Nested loops suck.  showModalDialog sucks :-)</div>
<div><br></div><div>-Darin</div>