W3C home > Mailing lists > Public > public-geolocation@w3.org > September 2014

Re: Geofencing alternative proposal

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 15 Sep 2014 20:42:55 -0700
Message-ID: <CABkgnnUCei0xTy5eGMwhJAxbdcqYqSyaLSfgPXtim_M7waM4_Q@mail.gmail.com>
To: Marijn Kruisselbrink <mek@google.com>
Cc: public-geolocation@w3.org
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.

> 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.

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.
Received on Tuesday, 16 September 2014 03:43:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:09 UTC