Re: Geolocation API Github Repo and Spec Editors

1) The spec page is then hosted at
http://w3c.github.io/geolocation-api/spec-source.html, BTW.  Did you want
to rename it as "index.html"?
2) Did you want to put in sub-page directories for geofencing proposals,
etc?  I'm happy to issue a PR for this, just don't know what structure
you'd like.
3) I'm also happy to be an editor if it would be helpful.


On Thu, Jul 24, 2014 at 5:39 AM, Mandyam, Giridhar <mandyam@quicinc.com>
wrote:

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