Re: Geofencing API - next steps?

or . . .

c) Continue to work withe the ServiceWorkers Working Group
https://github.com/slightlyoff/ServiceWorker/issues/898 on a standard for
implementing
navigator.serviceWorker.registration.travelManager.subscribe(options) so
that GeoLocation can continue to be tracked while the WebApp is in the
background in an efficient and battery-friendly way. A TravelEvent will be
delivered from the User Agent (or optimized to a more lightweight ambient
OS specific daemon such as Google Play) once an interesting location change
has taken place. This TravelEvent suffices to instantiate a ServiceWorker
that in turn could spin up a browser and/or tab. "Geofencing" is simply 20
lines of Javascript on top or, far more importantly, something that can be
delegated to the Application Server and subsequently PUSHed to interested
parties.

The case for GeoLocation being just another Generic Sensor has yet to be
made let alone proven. I personally can see the argument but then why have
a PushManager when a "MessageMailbox" could be just another sensor? Why
have DateTime, Interval, and Timeout when you have a Clock sensor?

Why make everything look like a nail 'cos all you want to use is a hammer?

Cheers Richard Maher

On Thu, May 19, 2016 at 10:31 PM, Mandyam, Giridhar <
mandyam@qti.qualcomm.com> wrote:

> As per the announcement below, I am not aware of any pending
> implementations of this API.  Given the need for interoperable
> implementations in order to progress a specification along the W3C
> standardization track, it does not seem to be possible to move forward with
> this specification as is.
>
>
>
> I am sending this message as an open call to the group to see if there is
> any interest in continuing to work on the specification as it currently
> stands.  Particularly for browser vendors, if there is expressed interest
> in continuing the work please also state implementation plans.
>
>
>
> If there is no expressed interest, then the following steps are possible:
>
>
>
> a)      Transition the existing API to a W3C Note.  This is essentially a
> parking space for a standard that did not achieve completion but could be
> picked up again in the future if there is interest and need.
>
> b)      Start working with the Devices and Sensors Working Group on
> supporting Geofencing use cases as part of their Generic Sensor work.  Note
> that Marijn has raised this issue already
> https://github.com/w3c/sensors/issues/73.
>
>
>
> I thank Marijn for his efforts on the specification.
>
>
>
> If there are no responses to the mailing list by May 27, 2016, 11:59 PM US
> Pacific time, then I will assume that there is group consensus for the next
> steps as proposed.
>
>
>
> -Giri Mandyam, Geolocation Working Group Chair
>
>
>
> *From:* mek@google.com [mailto:mek@google.com] *On Behalf Of *Marijn
> Kruisselbrink
> *Sent:* Wednesday, May 11, 2016 11:40 AM
> *To:* public-geolocation@w3.org
> *Subject:* No longer working on Geofencing API
>
>
>
> For quite a while now the geofencing API hasn't been much of a priority
> for us. Now in addition to that we're no longer convinced the geofencing
> API in its current shape is the best way to address the use cases we're
> interested in addressing. So with that in mind we've decided to stop work
> on the geofencing API in its current form.
>
>
>
> Marijn
>