Re: Geofencing API proposal

On Tue, Sep 9, 2014 at 11:33 AM, Stephen Li <stephenl@codeaurora.org> wrote:

> Hi Marijn,
>
>
>
> Here are a few comments (based on previous discussions at WG)
>
>
>
>    1. *Location unknown*
>
> partial interface ServiceWorkerGlobalScope
>
> {
>
>   attribute EventHandler ongeofenceenter;
>
>   attribute EventHandler ongeofenceleave;
>
> };
>
>
>
> Can we have a way to notify App when Location is unknown? This might be a
> system wide notification applying to all registered geofences, comparing
> with enter/leave usually applying to a specific individual geofence.
>
Something like that might be useful, although I'm not quite sure of the
implications (or usecases) of exposing such an event. What does it mean for
the Location to be unknown? This also gets back to accuracy of location. If
GPS location drops, but IP based location is still available, do you count
that as unknown? And is "location is unknown" somehow different from "user
disabled geolocation"? I think "user disabled geolocation" might actually
be more useful than "location is unknown". But in either case when the
location eventually does become known again the enter/leave events for the
movement from the last known location will be delivered anyway, so I'm not
sure if there really is a use case for knowing when the location is unknown.

>
>
>    1. *MIN/MAX_RADIUS*
>
>
>
> interface CircularRegion : GeofencingRegion {
>
>   const double MIN_RADIUS = 10;
>
>   const double MAX_RADIUS = 1000;
>
>   readonly attribute GeolocationPoint center;
>
>   readonly attribute double radius;
>
> };
>
>
>
> How would MIN/MAX_RADIUS be used? 10/1000 meters might not meet the needs
> for future usage.
>
Also see my other reply, I agree MIN_RADIUS is not useful, and MAX_RADIUS
is also of limited usability, so I've dropped these from my updated
proposal I'm about to send.

>
>
>    1. *User selected region*
>
>
>
> If we cannot find a strong reason for having it, I would suggest to not
> include it for now.
>
Agreed.

>
>
>    1. *Motivation*
>
>
>
> I checked out the blink page below. I am in agreement with the motivation
> stated on the page. If “energy efficient” is the main motivation, then do
> we need to let App know if the implementation is really “energy efficient”?
> A geofence solution can be implemented with poll/watch at OS level; having
> an App using such a solution without knowing the significant power
> difference will be against the purpose.
>
>
>
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_0boQVzUaXI
>
> Motivation
>
> This API will allow web applications to react to changes in the users
> location without having to poll/watch the position constantly (allowing the
> device to be more energy efficient). Essentially it allows web applications
> to do things based on physical proximity of the device to specific
> locations.
>
>
>
>
>
> *From*
>
> *: Marijn Kruisselbrink <mek@google.com
> <mek@google.com?Subject=Re%3A%20Geofencing%20API%20proposal&In-Reply-To=%3CCA%2BOSsVafYJSnEiFwyjCWYcyr%3D%2BGAdYTsm5CTi03owzjhmJmO5A%40mail.gmail.com%3E&References=%3CCA%2BOSsVafYJSnEiFwyjCWYcyr%3D%2BGAdYTsm5CTi03owzjhmJmO5A%40mail.gmail.com%3E>> Date:
> Wed, 23 Jul 2014 14:13:29 -0700**Message-ID**:
> <CA+OSsVafYJSnEiFwyjCWYcyr=+GAdYTsm5CTi03owzjhmJmO5A@mail.gmail.com
> <GAdYTsm5CTi03owzjhmJmO5A@mail.gmail.com>> *
> *To: public-geolocation@w3.org
> <public-geolocation@w3.org?Subject=Re%3A%20Geofencing%20API%20proposal&In-Reply-To=%3CCA%2BOSsVafYJSnEiFwyjCWYcyr%3D%2BGAdYTsm5CTi03owzjhmJmO5A%40mail.gmail.com%3E&References=%3CCA%2BOSsVafYJSnEiFwyjCWYcyr%3D%2BGAdYTsm5CTi03owzjhmJmO5A%40mail.gmail.com%3E> *
>
> 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
> <mek@google.com?Subject=Re%3A%20Geofencing%20API%20proposal&In-Reply-To=%3CCA%2BOSsVafYJSnEiFwyjCWYcyr%3D%2BGAdYTsm5CTi03owzjhmJmO5A%40mail.gmail.com%3E&References=%3CCA%2BOSsVafYJSnEiFwyjCWYcyr%3D%2BGAdYTsm5CTi03owzjhmJmO5A%40mail.gmail.com%3E>
> >
>
> 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* Wednesday, 23 July 2014 21:13:56 UTC
>
>
>