Re: [whatwg] Popular Background Geolocation question on StackOverflow

2018-03-25 6:29 GMT+02:00, Roger Hågensen <rh_whatwg@skuldwyrm.no>:
> On 2018-03-24 22:32, Andy Valencia wrote:
[...]
>> We're all well aware of the behaviors which make browsers adopt such
>> defensive measures.  Are we looking at enough use-cases to think about
>> some
>> sort of general authorization for background resource consumption, rather
>> than
>> continuing the point solution approach?
>
[...]
> I've kinda derailed this topic and we've got a three headed hydra now.
> Geolocation background tracking.
> Environment/general sensor API with background logging.
> Background task permission API for sensors or other general purposes.
>
> Regardless of use cases or apis is tied into this, one thing is clear.
> The user must either implicitly or explicitly initiate or agree to
> background processing. Some form of UI would be needed to give oversight
> over background browser tasks too.
[...]

I think a general solution for background processing would be
absolutely desirable. Some additional use-cases would be chats or
multiplayer games - i.e. realtime applications where it's important to
know whether a current user is still present or has dropped out.

2018-03-24 22:12 GMT+01:00, Roger Hågensen <rh_whatwg@skuldwyrm.no>:

[...]

>> E.g., a web page could ask the browser to continously record location
>> changes and - at some time at the browser's discretion - push a list of
>> recorded changes to the page.
>
> Hmm! It might.
> certainly it makes sense to cache location coords since the device may
> not have a internet connection during the entire time.
>
> In practice it would only need a internet connection at the time of data
> submission to the site of the webapp, the rest of the time it could be
> "offline".
>
>> This would allow the browser to record locations changes with reasonably
>> accuracy *without* waking up service workers.
>
> THis part I'm unsure of. Should it be a webapp or a client feature with
> a API for webapps?

[...]

By "push" I meant triggering a javascript event/callback in the web
page that requested the recording in the first place. (Either directly
in the corresponding tab/window or in a service worker)

I didn't mean that the browser itself should send the recording over
the network.
(Though it would certainly be useful if the web page could indicate
"wait until there is internet before you call me back", to simplify
the case where *the page* then immediately passes-on the result to a
server)

(Anyway, this whole idea seems now obsolete in light of the current
discussion, so this is just for the record.)

Received on Sunday, 25 March 2018 18:00:26 UTC