Re: Geolocation API Github Repo and Spec Editors

1. no, that's what I meant - just that we have a start on geolocation v2,
and we've been kicking around multiple proposals for geofencing, which may
be the same or different specs but probably are not the same level of
"baked" just yet.  I just wanted to understand if there was already an
understanding about where to put those.

2. OK.  Will follow up.


On Thu, Jul 24, 2014 at 1:02 PM, Mandyam, Giridhar <mandyam@quicinc.com>
wrote:

>  Chris,
>
> I will send an email to the group announcing your appt. as co-editor.
> Thanks for stepping up.
>
>
>
> 1.       I will leave it to you to work with Stephen and Ravi on
> organization of the repo.  When you are ready to release the an ED, you can
> certainly host it at the repo as index.html under a gh-pages branch.  What
> is at http://w3c.github.io/geolocation-api/spec-source.html is simply the
> starting point.  Or maybe I misunderstood your request?
>
>
>
> 2.       Regarding how you want to handle proposals, I think PR is fine
> at this point but I will leave it to you and your co-editors to decide.
>
>
>
> -Giri
>
>
>
> *From:* Chris Wilson [mailto:cwilso@google.com]
> *Sent:* Thursday, July 24, 2014 9:11 AM
> *To:* Mandyam, Giridhar
> *Cc:* Peter Beverloo; Marijn Kruisselbrink; public-geolocation@w3.org;
> Ravikumar Dandu; Li, Stephen
> *Subject:* 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.
>
>
>
>
>
>
>
>
>