Re: [w3c/ServiceWorker] Expose GeoLocation to workers (#745)

@pietie 
 
Can you please briefly explain your business/GPS requirements?
 
@chaals 
 
>  There's the Wake Lock API proposal.
 
A very good proposal! This is needed over and above Background Geolocation. One is a screwdriver and the other is a spanner.
 
If I want navigation in my car, or I want to watch a cycle, car, or yacht race then I want the screen-lock. (I personally have no use for a CPU lock but others clearly do. Console/Monitor perhaps?) This functionality stops the user from regularly swiping the screen to keep it alive and allows the user to go hands-free and watch a movie, race, or map at more than arms-length. Excellent and essential stuff, but ridiculously hungry on battery power.
 
Background GeoLocation OTOH, allows the Web App to be backgrounded or the phone to go to sleep and be put into the Dominos delivery guy’s pocket, and yet  interesting[1] location updates are still delivered to an existing Service Worker or a new Service Worker is instantiated for appropriate action. This paradigm plays well with SW re-usability, as a single SW can often survive and service an entire journey yet none will be consuming resources while the user is at rest. The SW is free to XHR/Fetch the location update to the fleet management server so that the end-customer can see exactly where their pizza is or you can watch Larry Ellison’s progress around Bermuda. NB: That the spec does not mandate that an a full-blow UA be instantiated by an implementation during this time, just whatever minimalist run-time environment and eco-system is required to keep an SW viable.
 
For any given GeoFence, a server may decide to Push a notification to the Web App telling it to foreground itself or at least tell delivery-guy that attention is required. Location updates can also be queued up by the SW as postMessage() calls so that when the Web App *is* foregrounded again it can drain the pipe/queue. (I’d like a way to collapse SW post messages to the client just like Push Messages can be collapsed by Firebase. Maybe it’s there already?)
 
Look I have plenty of detail to go around these bones but you get the idea right? Extremely battery and memory friendly yet full-featured essential Web App functionality.
 
Now on to your suggestion: -
 
> A quick look suggests that adding "locationTracking" to the specified wake lock types wouldn't
> be all that hard,
 
Actually, I reckon it’s nigh impossible.  Hardware implementations, that I don’t understand aside, that sort of resource-allocation granularity just doesn’t exist or make sense (at least to me :-) How can the CPU be asleep for the Web App yet Javascript be freely available to service the location update? So I suggest that you are opting for a CPU/SYSTEM lock. The screen will sleep but all timer Events and any/all none screen emanating events will continue to fire and the CPU will be run down.
 
There may well come a time where mobile battery lifetime is not an issue, just like disk seek time is not an issue any more, but not in my lifetime.
 
> and it would deal with the issue @RichardMaher raised of not needing e.g. the
> screen to stay on.
 
Can you see the sophistication and superiority of my proposal? Much better to capture your troika/bike rides for posterity. WakeLocks are great! We need them! Just not for “Background” GeoLocation.
 
> There is a privacy issue of course, and implementing this in a way that gives
> users meaningful control is non-trivial.
 
Agreed. Many options available. Good experienced spec writers needed.
 
[1] “Interesting” location updates are those that meet the filter criteria specified as options when the serviceWorkerRegistration.TravelManager.subscribe({options . . .}) call. This acts as a throttle against a burst of location updates.
 
Ø  MinJourney. Meters that must be travelled before reporting the location change.

Ø  MinTime. Millisecs that must elapsed before reporting a location change.

Ø  MaxSilence. Doubles as a sanity check that everything is still working and an opportunity to report a change previously delayed by MinTime. (Position.timestamp must reflect the original value)

Ø  Accurate. Use accurate power-expensive feeds where available.

Ø  MaxAge: Maximum number of millisecs between now and Position.timestamp before reading is considered stale.

Happy to work through the privacy issues here if someone is up for it?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/745#issuecomment-304168724