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

Re: Geofencing API proposal

From: Peter Beverloo <beverloo@google.com>
Date: Thu, 24 Jul 2014 14:18:44 +0200
Message-ID: <CALt3x6kPZ0CZ4XJSQ1=EfEwftV6nHSLfDUkDD=_BT6eQuQXSgg@mail.gmail.com>
To: Marijn Kruisselbrink <mek@google.com>
Cc: public-geolocation@w3.org
Hi Marijn,

Thanks for the proposal! I think it's definitely a good document to kick
off discussions about how we could support geofencing on the Web.

This thread currently encapsulates the API, an updated version of said API
and proposed solutions for a rather large open question, the event delivery
model for this feature. I worry that this makes it difficult for this
thread to remain focused.

Perhaps we should take a step back, and first define the problem which we
actually want to solve (e.g. looking at the use-cases in much more depth,
writing example code to see how the proposed API(s) would solve them). It
would also be great if there could be a GitHub repository; not just for the
storing specification's drafts, but also to track open suggestions,
concerns and issues.

Thanks,
Peter


On Wed, Jul 23, 2014 at 11:13 PM, Marijn Kruisselbrink <mek@google.com>
wrote:

> 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.
>>
>>
>>
>>
>
Received on Thursday, 24 July 2014 12:19:12 UTC

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