Re: Geofencing alternative proposal

On Fri, Sep 19, 2014 at 12:13 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 19 September 2014 09:23, Marijn Kruisselbrink <mek@google.com> wrote:
> > Then maybe I'm misunderstanding how service workers work, but how I
> > understand it the "install" event is ran once, essentially the first
> time a
> > particular service worker version is loaded. Once a service worker is
> > installed and activated a browser is free to completely throw away all
> > javascript state associated with the service worker, and later
> reload/rerun
> > it from scratch when it has some event to deliver to the service worker
> (by
> > doing it this way a service worker that isn't currently processing any
> > events uses no resources at all). This means that even if somehow the
> > browser would keep track of which geofences have event handlers
> associated
> > to them by a particular service worker, this doesn't help since the event
> > handler itself would no longer exist when the service worker file gets
> > loaded again. Service workers and all the javascript objects/closures/...
> > generally only exist for the duration of handling an event.
>
> We can ask someone who knows better, but my understanding is that the
> "scope" and other determining attributes (the events that the SW is
> registered to handle) are maintained.  Fences would be one of those
> things.
>
Oh yes, I'm not saying that registered fences and other properties like
that won't be maintained. But the actual event handler itself is a closure
that can potentially hold references to any other bit of javascript state,
so to maintain event handler bindings in arbitrary objects would mean
maintaining the full javascript state, which wouldn't be practical.
+Alex: Is my understanding correct here?