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

Ok, forgetting green-field implementation aspirations and fully embracing "we are where we are" pragmatism, the following is a very workable Background GeoLocation  permissions solution: -

 The [PositionsOptions Interface](http://w3c.github.io/geolocation-api/spec-source.html#position_options_interface) needs to be expanded to take:

- boolean enableBackgroundWatch = false  The UA will know to expect/accept a registration request with the TravelManager but, if not, who cares? ServiceWorker instantiation and TravelEvent delivery will **_only_** occur when the Client page/app is backgrounded or the phone is asleep i.e. It is the UA's responsibility decide when the mainline/client is incapable of receiving location events.  For permissions, If not perviously granted, user-permission must be sought clearly specifying "Background Location continuity" in the permission description. [This attribute will be ignored (thrown?) for getCurrentLocation] TODO: Although Location has a sub-permission of "accurate" (at least on Android) and now "background", there appears to be no way to set the sub-privileges individually. How do other privileges handle this granularity? Tickboxes?
- unsigned long minJourney = 0  If omitted there is no minimum distance required an all events will be delivered. [This attribute will be ignored (thrown?) for getCurrentLocation]
- unsigned long minInterval = 0  If omitted no period of time must elapse between location events,[This attribute will be ignored (thrown?) for getCurrentLocation]

Cons: -
1) I'm guessing UA implementations of watchPosition() are done in the Tab/App/process context and not globally at the UA. 
2) Messy having two registrations for the "same" event? TravelManager and watchLocation

-- 
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-306380914