Background Geolocation

[Tom333Trinity]

I am extremely enthusiastic to see recent works to resurect this spec to "Living Standard" status as confirmed here

Is now not the time to look to new features?

For 5 long years the user-base has managed to maintain the rage in this forum

And voices in the wilderness have gone unacknowledged let alone answered in the wider community

Is this really not more important/urgent than how error messages are localized?

The GeoLocation sensor API has proved to be a non-starter.

The Wake-Lock API will never bring in CPU lock and even then it would be a grossly inefficient square peg in a round hole.

Is there nowhere that technical professionals can debate the most appropriate solution to this essential functionality?

@chaals @ljwatson can I bring your attention specifically to ghost stories such as: -

"This group will reject changes to the service worker core that allows the service worker to be continually alive, particularly while the site is closed, as this would present a huge privacy abuse vector, and unnecessary battery use."

The proposed solution does not, i repeat DOES NOT, keep the service worker "continually alive"! The proof is in the code and the working example. Believe your eyes please.

The ratio of service worker instances to GeoLocation hits is imperical and observable!

[marcoscaceres]

Sorry, background geolocation remains outside the scope of this spec: we are restricting it to foreground requests. I'd suggest incubating a solution at the WICG and seeing if there is enough interest to standardize something.

[Tom333Trinity]

Please explain why you insist on cancelling active discussion of this feature. Where is the harm?

WICG has dead-ended on this topic with a redundant API deferring any novelle functionality to a mythical version 2+

It was declared out-of-scope for the Geolocation Sensor API because that API is simply incapable of supporting Background Geolocation. So what is stopping it becoming in scope here? Or it's own spec if that is more appropriate?

For 5 years you have been playing wack-a-mole with any mention of background geolocation in the face of huge demand from the client-base and web developers in particular.

How can W3C have achieved nothing in this area over 5 years yet still insist on stifling/cancelling debate?

[marcoscaceres]

Happy to chat, (assuming) Richard. What new information do you have?

[jyasskin]

In general, Living Standards are the right place for features with consensus across browser engines, while the WICG is right for features that are still developing to that point. It looks like https://discourse.wicg.io/t/proposal-expose-geolocation-to-service-workers/2588 is the right place to discuss this one.

[Tom333Trinity]

Thanks for re-opening @marcosceceres. I really appreciate it!

With regard to what's new: - 1) The Alternatives to the TravelManager solution have proven insecuer, unwanted, undeliverable and/or unworkable 2) Use Case and user demand has swollen to the point of utter frustration, forcing many devs to Native App solutions (See links above) 3) There will never be a CPU wake lock as deemed by all UA providers 4) The screen wake-lock is the most battery-unfriendly and inefficient solution that few Background Geolocation Use Cases require 5) Five Long years have passed with no progress https://github.com/w3c/geolocation-sensor/issues/44 6) At the OS level Android and iOS hav cracked down on even native Apps receiving too many Geolocation events

What's the same: - 1) The truth is not relative. The TravelManager was the correct solution then and it remains so today. 2) The sheer beauty of having the UA receive GPS updates rather than a Client or Service Worker means event throttling is out of the DEV's hands 4) Project Fugo means nothing without background geolocation 5) The TravelManager is also the solution for Geofencing; two for the price of one 6) The user base needs a place to register their dismay at the lack of this essential Web App functionality

[marcoscaceres]

Agree with @jyasskin, WICG is the right place to have this discussion. @Tom333Trinity, happy for you to formulate some ideas here, but then those should be moved to the WICG.

[Tom333Trinity]

What happen to "Happy to chat,"?

WRT @jyasskin and "consensus across browser engines," I must have missed a link to the consensus vote for https://github.com/w3c/geolocation-sensor/issues/44 could you provide one please?

And let's see, if we follow your link we come to: -

@JaiOwl, thanks for your input. This topic has graduated from incubation and the work is now underway in the Devices and Sensors Working Group. You can help by reviewing the Geolocation Sensor use cases that consider both foreground and background operations enumerated at https://w3c.github.io/geolocation-sensor/#use-cases 176 and submit feedback via https://github.com/w3c/geolocation-sensor/issues 110

Which inevetibly leads to w3c/geolocation-sensor#44

So I guess, once more, you're asking me to go fetch a left-handed screw driver or a tin of striped paint? For another 5 years?

@marcoscaceres I'm happy for you to move the conversation anywhere the free exchange of ideas can take place!

But it is my great lament that a working example SSCCE has been wilfully ignored for so long :-( Tell me what is wrong with it?????

Anyway I will add a Screen Lock to BrotKrummen to make it easier to demonstrate and get back.

[marcoscaceres]

What happen to "Happy to chat,"?

We are chatting :) but at the same time...

But it is my great lament that a working example SSCCE has been wilfully ignored for so long :-( Tell me what is wrong with it?????

Nothing wrong with it. It's probably amazing. However, implementers aren't yet at the point where they are ready to invest in this area. That doesn't prevent folks like yourself coming up with ideas around how it could work, use cases, and even some sort of API shape. Why we keeping pointing to the WICG as the place to do that.

Anyway I will add a Screen Lock to BrotKrummen to make it easier to demonstrate and get back.

Sounds good.

[Tom333Trinity]

Waiting on chrome bug. I think?

[marcoscaceres]

@Tom333Trinity, sorry, what's the relationship between that chrome bug and this issue?

[Tom333Trinity]

Sorry, I've added the Screen Lock code it's not currently passing the Lighthouse PWA checks due to that bug and I want to make the example as easy to use as possible. Apparently the bug is fixed so it shouldn't be too long now.

[marcoscaceres]

@Tom333Trinity don't get grumpy, but I'm going to close this as it remains out of scope here. We will eventually find a home for this.