Re: Geofencing API proposal

I incorporated some feedback I got and posted a new IDL file at
https://gist.github.com/mkruisselbrink/b68110599a986bb9c963 (I'm sure my
IDL isn't perfectly valid webidl, and the naming of various
structures/methods isn't great either, but hopefully the intent is clear).
The main changes here are the new getRegionState method, and addition of a
position attribute to the enter/leave events (the other potential region
types at the bottom are more illustrative than that I'm actually proposing
to include those).

Other feedback I've gotten is that it would be nice to be able to use
geofencing in webpages without service workers as well. I agree that this
could be beneficial, but it raises some questions about the scoping of
geofence registrations. If Service Workers are a requirement, like in my
current proposal, the most obvious thing to do is for geofence
registrations to always be scoped to the serviceworker associated with the
page the registration was made from. If you also allow registration from
web pages without service workers, it is less clear what the best option
is. The options I can think of are:

Option 1: Have completely separate scopes for geofences registered in
service workers and geofences registers in webpages. A geofence that is
registered in a service worker will only trigger events in that service
worker, and a geofence that is registered in a webpage will only trigger
events in that particular webpage (and the lifetime of the registration is
also linked to the lifetime of the webpage). If a webpage wants to register
a geofence for its associated service worker it will need to post message
to the service worker and have the service worker do the actual
registration.

Option 2: If a geofence is registered in a web page without an active
service worker, the registration is scoped to that webpage and events get
delivered to the webpage. If however a geofence is registered in a web page
with an active service worker, the registration is scoped to the service
worker, and events are only delivered to the service worker. Geofences that
are registered from the service worker also only trigger events in the
service worker.

Option 3: Give webpages a choice when registering a geofence. Add some kind
of flag that specifies if the registration should be scoped to the webpage
or to the service worker.

All these options have in common that every service worker registration
only results in events being dispatched in one context. Another set of
options would be to dispatch geofence enter/leave events in all pages that
share a service worker, or in just the one webpage that registered a
geofence as well as in its service worker (but not in other webpages). I
think going this way would quickly lead to madness and needless complexity
though.

Of these options I think option 1 would be the simplest option while still
fulfilling all the use cases. The other options might make some things
easier, but are also less consistent and have more potential for confusion,
without enabling anything that isn't possible in option 1.

Any thoughts?


On Fri, Jul 18, 2014 at 9:51 AM, Marijn Kruisselbrink <mek@google.com>
wrote:

> Hi, I’m a Software Engineer working on blink/chrome at Google. I’m
> currently working on brining Geofencing to Service Workers/the web, so here
> is a proposal for an API for that.
> Use cases
>
>    -
>
>    Companies presenting their Web app based on the user’s locality (e.g.
>    showing their membership card # when they’re in a store).
>    -
>
>    Web apps for assisting the user based on their locality (e.g.
>    calendars, alarms, reminders, accessibility devices and so on).
>    -
>
>    Similarly, Web apps showing photo spots, events and transport
>    information based on the user’s locality (similar to Google Now).
>    -
>
>    Offers or discounts presented to a user when they’re near a store.
>
> API proposal
>
> [exposed=Window&Worker]
>
> partial interface Navigator {
>
>    readonly attribute Geofenci
> <http://dev.w3.org/geo/api/spec-source.html>ng geofencing;
>
> };
>
> partial interface ServiceWork
> <https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md>erGlobalScope
> {
>
>   attribute EventHandler ongeofenceenter;
>
>   attribute EventHandler ongeofenceleave;
>
> };
>
> The ongeofenceenter and ongeofenceleave events have a “region” attribute
> with the relevant GeofencingRegion.
>
>  [NoInterfaceObject]
>
> interface Geofencing {
>
>    Promise<undefined> registerRegion(GeofencingRegion region);
>
>    Promise<undefined> unregisterRegion(DOMString regionId);
>
>    Promise<sequence<GeofencingRegion>> getRegisteredRegions();
>
> };
>
> Possible failure reasons for registerRegion include no service worker
> being associated with the page, the user not accepting the location
> request, and maybe others. If an attempt is made to register a region with
> the same ID as that of a region that is already registered, the new region
> will override the old region.
>
> Possible failure reasons for unregisterRegion include no region being
> registered with the given ID.
>
> The getRegisteredRegions method returns all currently registered regions.
>
> The promise is resolved to a (potentially empty) list of GeofencingRegions
> on success, and rejected on failure to get the regions. A possible failure
> reason would be no service worker being active for the page. No regions
> being registered is not a failure.
>
> Regions are specified by the following API:
>
> [NoInterfaceObject]
>
> interface GeofencingRegion {
>
>   readonly attribute DOMString id;
>
> };
>
> [Constructor(optional String? id, dictionary options),
> exposed=Window&Worker]
>
> interface CircularRegion : GeofencingRegion {
>
>   const double MIN_RADIUS = 10;
>
>   const double MAX_RADIUS = 1000;
>
>   readonly attribute double latitude;
>
>   readonly attribute double longitude;
>
>   readonly attribute double radius;
>
> };
>
> All regions may be referred to by a string identifier. Exactly one region
> can be registered per identifier.
>
> The radius is specified in meters, and must be between MIN_RADIUS and
> MAX_RADIUS (inclusive). The values of MIN_RADIUS and MAX_RADIUS may be
> platform dependent.
>
> If no id is provided the empty string is used. Latitude, longitude and
> radius must always be provided.
>
>
>
>