Re: Geolocation API Github Repo and Spec Editors

Hi Peter, Marijn,
    Great ideas. We can create a doc at the github geolocation-api on the use cases to solve. Here is a first draft list:

1)Action generated when User enters an area 
   examples: 
    WebApps auto-checkin to a hotel when user enters the hotel  
    Businesses sending advertisements, offers, discounts, when device gets close to their store. 
    Reminder App sends event on todo items when close. eg: reminder to buy a batteries when within proximity of a retail shop 
   
2)Action generated when User exits an area
   examples:
    When user exits office, sends a text to spouse stating will be home in X minutes.  
    When user exits home, app makes sure the lights are turned off

Regards
Ravi 

----- Original Message -----
From: "Giridhar Mandyam" <mandyam@quicinc.com>
To: "Peter Beverloo" <beverloo@google.com>, "Marijn Kruisselbrink" <mek@google.com>
Cc: public-geolocation@w3.org, "Ravikumar Dandu" <rdandu@mozilla.com>, "Stephen Li" <stephenl@qca.qualcomm.com>
Sent: Thursday, July 24, 2014 2:39:19 PM
Subject: Geolocation API Github Repo and Spec Editors

Hello All,
A github repo has been created:  https://github.com/w3c/geolocation-api.

In addition, Ravi Dandu of Mozilla and Stephen Li of Qualcomm Atheros have stepped up to be co-editors.

-Giri Mandyam, W3C Geolocation WG Chair

From: Peter Beverloo [mailto:beverloo@google.com]
Sent: Thursday, July 24, 2014 5:19 AM
To: Marijn Kruisselbrink
Cc: public-geolocation@w3.org
Subject: Re: Geofencing API proposal

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<mailto: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<mailto: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 Friday, 25 July 2014 11:35:16 UTC