<div class="gmail_quote">On Wed, Sep 9, 2009 at 11:30 AM, 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:23 AM, Darin Fisher<<a href="mailto:darin@chromium.org">darin@chromium.org</a>> wrote:<br>
> On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman <<a href="mailto:aa@google.com">aa@google.com</a>> wrote:<br>
</div><div class="im">>> There would presumably have to be a separate name value for each API,<br>
>> though, right? So we're talking about the difference between:<br>
>><br>
>> window.acquireLock("localStorage", function() {<br>
>> ...<br>
>> });<br>
>><br>
>> and:<br>
>><br>
>> window.acquireLocalStorage(function() {<br>
>> ...<br>
>> });<br>
>><br>
>> It doesn't seem like much of a win for reusability IMO.<br>
><br>
> I wanted to leave it up to the app developer to choose the name so that they<br>
> could define how the lock is interpreted.<br>
> For example, they might want to partition the keyspace for local storage and<br>
> have separate locks for separate keys.  Or, they might want to have a single<br>
> lock that is inclusive of several storage mechanisms: LocalStorage and<br>
> FileAPI.<br>
> Besides, once we have an explicit locking API, why not just be generic and<br>
> give it a name divorced from LocalStorage or any kind of storage features<br>
> for that matter?  Locking can be useful to other applications that do not<br>
> even use local storage...<br>
<br>
</div>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></blockquote><div><br></div><div>Yes, exactly. Sorry for not making this clear.  I believe implicit locking for LocalStorage (and the implicit unlocking) is going to yield something very confusing and hard to implement well.  The potential for dead locks when you fail to implicitly unlock properly scares me.</div>
<div><br></div><div>-Darin</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>
<font color="#888888"><br>
- a<br>
</font></blockquote></div><br>