Re: Geofencing alternative proposal

On Mon, Sep 15, 2014 at 8:42 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> As I noted on the other thread, these are looking pretty close.
>
> On 15 September 2014 17:03, Marijn Kruisselbrink <mek@google.com> wrote:
> > I deliberately left out/didn't address many details in my initial
> proposal,
> > since trying to address every little detail in one go didn't seem like a
> > very productive way to get anywhere. But maybe I should have addressed
> some
> > of these details a bit more up front, since it might have made some of my
> > design choices more clear. I was kind of expecting to get some
> > feedback/questions which would then give me the opportunity to address
> these
> > details, but that unfortunately didn't happen.
>
> I apologize for not getting you feedback; I have barely had enough
> time to rework what I had previously done.
>


> > I'm not sure if there is much value in exposing the existing Geolocation
> API
> > to service workers? While it might be useful to be able to call
> > getCurrentPosition from a service worker, I'm not entirely sure what the
> use
> > case for that would be (maybe something like a find-my-device service,
> where
> > a service worker might want to react to receiving a push message by
> posting
> > back the current location?).
>
> There are cases where push event suppression could be location-based,
> which would necessitate a call.  For instance, if an application were
> to say: don't notify me when I'm in the theatre.  (It would be awesome
> if geolocation were good enough some day to make that possible ;)
>
> >> [ISSUE] The GeolocationFence objects that are returned from this
> >> context aren't going to be functional - events can't surface in the
> >> window, they will only appear in the worker.  I don't know if it is
> >> worth creating parallel interfaces for this purpose that don't produce
> >> events, or whether we can just neuter those objects (i.e., make the
> >> events not fire).  There are benefits to either approach.
> >
> > I'm not entirely sure what the purpose is of the
> > GeolocationWorkerRegistration layer between the ServiceWorkerRegistration
> > and the GeolocationFenceControl? Is the idea here to use this as an
> > indicator that the website is asking for background geolocation
> permissions
> > (and if that's the intention, would it make sense to have a more explicit
> > way of asking for this permission?)
>
> The point is that the API has three discrete stages:
>
> // 1. create a service worker
> navigator.serviceWorker.register(script).then(sw => {
>   // 2. register interest in geolocation
>   return sw.geolocation.register();
> }).then(geo => {
>   // (optional) 3. register interest in specific areas
>   // ...optional because the SW itself might perform the registrations
>   return geo.register(area);
> });
>
> > The entire Geolocation (and thus GeolocationFenceControl) object is
> already
> > exposed to both websites and service workers in your proposal, so this
> > doesn't seem to add much.
>
> Only if you assume that access to these events are of no interest to
> sites with active windows.  Or that you will require a service worker
> in order to access this feature at all.  I've not been assuming that.
> An active window will have different ways of dealing with events.
>
Yes, it's true that currently my API proposal requires a (empty) service
worker in order to use this feature, which doesn't seem like it would be an
entirely unreasonable requirement, and I think it does help simplify the
API a bit.

> While localizing events like this works perfectly fine for regular
> websites,
> > I don't see how this is going to work for service workers. What happens
> when
> > a browser tries to deliver a geofence event to a service worker? Assuming
> > the service worker isn't currently running, the browser will create a
> fresh
> > javascript context (in which no GeolocationFence instances exist), load
> the
> > service worker, and then won't have anywhere to actually deliver the
> event.
>
> The SW code can query the active GeolocationFence objects to determine
> where events might arrive.
>
Can you give some sample code how this would look like with your API? I'm
not quite following how it could. So the browser would "wake up"
(essentially load from scratch) a service worker, and would then have to
somehow wait for the service worker code to install event handlers on the
right geofences? But to get to a GeolocationFence object it would need to
do possibly asynchronous API calls, so it's not clear to me how this
waiting could work.

>
> I will concede that the "id" is useful here, since it allows a site to
> persist state specific to a fence and re-correlate.  (I was already on
> the fence about this.)  I just find "id"-based APIs distasteful; but I
> can certainly live when them.
>
> > I agree that some kind of error event will probably be necessary,
> although
> > I'm not sure about the exact shape. But some way of indicating that a
> > geofence is no longer registered might be nice to have. Although ideally
> it
> > would never be needed to send this event of course. As long as
> geofencing in
> > general is available, the browser should do everything it can to keep all
> > registrations active, and I'm not really sure under what circumstances
> only
> > a subset of geofences would somehow unregister itself.
>
> As I noted in my mail, I'm not sure if this is particularly
> compelling.  If we can determine that fences can be maintained
> indefinitely (which might require some hacks if there is hardware
> support and that support is limited somehow), then the only thing we
> need to worry about here is the transient errors.  That means no new,
> fatal code.  Which would be ideal.  I'll have to rely on folks with
> greater familiarity with the hardware to yell if this is a problem for
> them.
>
> I mostly included this because I wanted to make sure we'd properly
> considered the options.
>