[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

WebApp future and People Power

Richard Maher

2/19/2016 2:06:00 AM

I beg all of you who are interested in the growth of HTML5 functionality and the future of browser-hosted web-apps to read the following: -

https://github.com/w3c/geofencing-api...
https://github.com/slightlyoff/ServiceWorker/...

I understand the concerns about privacy and battery-life and am more than happy to address them in a lively debate.
3 Answers

Richard Maher

2/21/2016 12:02:00 AM

0

On 19-Feb-16 10:06 AM, maherrj@googlemail.com wrote:
> I beg all of you who are interested in the growth of HTML5 functionality and the future of browser-hosted web-apps to read the following: -
>
> https://github.com/w3c/geofencing-api...
> https://github.com/slightlyoff/ServiceWorker/...
>
> I understand the concerns about privacy and battery-life and am more than happy to address them in a lively debate.
>

Ok Option 2.

Please just add yourself to the CC list for
https://bugzilla.mozilla.org/show_bug.cgi?...

Star this issue
https://bugs.chromium.org/p/chromium/issues/detail?...

"Monorail" what a joke

Richard Maher

5/12/2016 2:10:00 AM

0

On Friday, February 19, 2016 at 10:06:23 AM UTC+8, mah...@googlemail.com wrote:
> I beg all of you who are interested in the growth of HTML5 functionality and the future of browser-hosted web-apps to read the following: -
>
> https://github.com/w3c/geofencing-api...
> https://github.com/slightlyoff/ServiceWorker/...
>
> I understand the concerns about privacy and battery-life and am more than happy to address them in a lively debate.

A victory for common sense. Excellent news!

On Thu, May 12, 2016 at 2:40 AM, Marijn Kruisselbrink <mekATchromium.org> wrote:
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

Combine that outcome with this at the upcoming TPAC: -

Hello All,

The registration for TPAC 2016 is now open - relevant information is provided in the email attachment below. There will not be a stand-alone meeting for the Geolocation Working Group, but there will likely be a joint meeting between the Geo WG and the Devices and Sensors (DAS) WG. This should be confirmed soon, and will take place during the DAS WG's allocated meeting time (Sep. 19-20).

Thanks,

-Giri Mandyam, Geolocation Working Group Chair

An the scene is set for a ServiceWorker.TravelManager.subscribe() outcome or, more likely, a generic sensor.AddListener(filterOptions). Either way these are exciting times indeed. Good Luck!

Richard Maher

5/23/2016 12:35:00 AM

0

The good news is we killed Geofencing! The bad news is you have until May 27 to submit alternative use-case solutions before they waste more precious time trying to make geolocation into a "Generic Sensor" like ambient-light or temperature. Please join and respond to the public list "public-geolocation(AT)w3.org: -


On Fri, May 20, 2016 at 8:42 AM, Richard Maher <maherrj@> wrote:
or . . .

c) Continue to work withe the ServiceWorkers Working Group https://github.com/slightlyoff/ServiceWorker/... 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@> 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....


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@ [mailto:mek@] On Behalf Of Marijn Kruisselbrink
Sent: Wednesday, May 11, 2016 11:40 AM
To: public-geolocationATw3.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