- From: Roger Hågensen <rh_whatwg@skuldwyrm.no>
- Date: Sun, 25 Mar 2018 06:29:12 +0200
- To: whatwg@lists.whatwg.org
On 2018-03-24 22:32, Andy Valencia wrote: > There are lots of apps using long-polling which would also like > to have some explicit (standards based) answers to their needs > to run when not the current tab--messaging and telemetry apps, > for instance. > > And here we are thinking about a hand crafted solution for GPS backgrounding. > > 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? Good point. And my example of a environment API was flawed as I just realized that a heart (pulse) sensor might be highly beneficial to tie into time and GPS and temperature and other sensor data. All this stuff could be lumped into a sensor API (or is there a existing one?) Another related example would be a loudness tracker, which would use the Microphone to record and calculate a loudness. One particular such use could be a baby monitor, letting you see how much noise/crying the baby does, maybe add in temperature or moisture sensor data if available. Or replace baby with dog or cat to detect barks or meowing while the pet owner is out of the house. A sensor api and a background permission api should probably be separate as I'll assume there might be other non-sensor uses that a user might want to do background processing. Perhaps a server uptime app, having the app reliably prod a server would be such a use case. Obviously a dedicated native app could do this much better, but it's a lot quicker to throw something together as a web app. And there is little to no need to roll out updates unlike native apps. I guess this is a chicken and an egg situation. You won't see use cases unless it's possible to actually implement them. It's not as much a "Should this be possible?" question as it is a "Why isn't this possible?" question. 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. While I did angle towards smart phones here there is no reason why a desktop can't also run background webapps, and there battery capacity is a non-issue (usually). Sorry for murkying the waters further on this. -- Unless specified otherwise, anything I write publicly is considered Public Domain (CC0). My opinions are my own unless specified otherwise. Roger Hågensen, Freelancer, Norway.
Received on Sunday, 25 March 2018 04:29:44 UTC