[whatwg] Application defined "locks"

[Darin Fisher]

On Thu, Sep 10, 2009 at 12:32 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:
>
>
>
> On Wed, Sep 9, 2009 at 7:55 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman <michaeln at google.com>wrote:
>>
>>> If this feature existed, we likely would have used it for offline Gmail
>>> to coordinate which instance of the app (page with gmail in it) should be
>>> responsible for sync'ing the local database with the mail service. In the
>>> absence of a feature like this, instead we used the local database itself to
>>> register which page was the 'syncagent'. This involved periodically updating
>>> the db by the syncagent, and periodic polling by the would be syncagents
>>> waiting to possibly take over. Much ugliness.
>>> var isSyncAgent = false;
>>> window.acquireFlag("syncAgency", function() { isSyncAgent = true; });
>>>
>>> Much nicer.
>>>
>>
>> How do you deal with the user closing the syncagent while other app
>> instances remain open?
>>
>
> In our db polling world... that was why the syncagent periodically updated
> the db... to say "still alive"... on close it would say "i'm gone" and on
> ugly exit, the others would notice the lack of "still alives" and fight
> about who was it next. A silly bunch of complexity for something so simple.
>
> In the acquireFlag world... wouldn't the page going away simply relinquish
> the flag?
>
>
> How would the pages that failed to acquire it before know that they should
> try to acquire it again? Presumably they would still have to poll (assuming
> the "tryLock" model).
>
> Regards,
> Maciej
>
>

In my proposed interace, you can wait asynchronously for the lock.  Just
call acquireLock with a second parameter, a closure that runs once you get
the lock.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/a871f07f/attachment-0002.htm>