[whatwg] Application defined "locks"

On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman <aa at google.com> wrote:

> On Wed, Sep 9, 2009 at 11:23 AM, Darin Fisher<darin at chromium.org> wrote:
> > On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman <aa at google.com> wrote:
> >> There would presumably have to be a separate name value for each API,
> >> though, right? So we're talking about the difference between:
> >>
> >> window.acquireLock("localStorage", function() {
> >> ...
> >> });
> >>
> >> and:
> >>
> >> window.acquireLocalStorage(function() {
> >> ...
> >> });
> >>
> >> It doesn't seem like much of a win for reusability IMO.
> >
> > I wanted to leave it up to the app developer to choose the name so that
> they
> > could define how the lock is interpreted.
> > For example, they might want to partition the keyspace for local storage
> and
> > have separate locks for separate keys.  Or, they might want to have a
> single
> > lock that is inclusive of several storage mechanisms: LocalStorage and
> > FileAPI.
> > Besides, once we have an explicit locking API, why not just be generic
> and
> > give it a name divorced from LocalStorage or any kind of storage features
> > for that matter?  Locking can be useful to other applications that do not
> > even use local storage...
>
> I see.
>
> So you are suggesting the localStorage could have zero concurrency
> guarantees and it is simply up to the developer to arrange things
> themselves using this new primitive.
>

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.

-Darin



>
> That is an interesting idea. You're right that it overlaps with the
> ideas that inspired shared workers, and the global script proposal.
>
> - a
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090909/da4886bf/attachment.htm>

Received on Wednesday, 9 September 2009 11:37:25 UTC