W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] Application defined "locks"

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 10 Sep 2009 12:32:54 -0700
Message-ID: <873AAE05-7003-4F44-96FC-46FEF76F71AC@apple.com>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/7c8cd590/attachment.htm>
Received on Thursday, 10 September 2009 12:32:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC