Re: Geofencing alternative proposal

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

> On 19 September 2014 13:26, Marijn Kruisselbrink <mek@google.com> wrote:
> > 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.
>
> Nothing I suggested would require that though.  Or have I misunderstood
> you?
>
Your sample code was:
this.addEventListener("install", e => {
  e.waitUntil(
    this.geolocation.geofence.getRegistrations().then(fences => {
      fences.forEach(fence => { fence.onenter = handleEnter; });
    })
  );
});

This code gets run once, on installation of the serviceworker. But from
your description it seems like you expect the association between specific
geofences and potentially arbitrary javascript closures (in your example
just 'handleEnter', but nothing seems to stop people from having much more
complicated event handlers) to survive killing and restarting the service
worker. For this to be possible it seems that the complete state of
whatever "handleEnter" is would need to be somehow maintained across
service worker kill/restart, which potentially can mean that the full
javascript state would need to be maintained, since there are no limits to
what handleEnter can do/be.