Re: [whatwg] Popular Background Geolocation question on StackOverflow
On 2018-03-25 07:17, Richard Maher wrote: If that makes sense for your App the background-fetch already caters for posting location updates to a fleet manager. ... If delayed Batch Processing is acceptable to your site and you don't want geofences then good luck. ... TravelManager register() and unRegister() I had to look up fleet manager and travelmanager. These are business terms. I did not consider fleet management, nor did I consider targeted traveling advertising/upselling (travelmanager?). I was looking at this from a non-commercial user standpoint as well as scientific standpoint. Hence why I mentioned "crowd sourcing" weather data and geolocation from smart devices via a webapp, or a health and fitness training app (pulse, distance, altitude etc), or health/wellbeing (baby monitoring, pet monitoring). But regardless of the intened use or purpose. Splitting things into a whole bunch of APIs and then trying to get permissions working for all of them is going to be a huge pain IMO. A general purpose permission system and a general purpose sensor api (that can gather gps and various other things like ambient temperature or pulse) would be a better long term goal. It would also be less likely to screw up security this way. -- 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.
Re: [whatwg] Popular Background Geolocation question on StackOverflow
On 2018-03-25 07:17, Richard Maher wrote: This would allow the browser to record locations changes with reasonably accuracy *without* waking up service workers. If you don't like how ServiceWorkers cater for the Fetch API than please take it offline with Jake and W3C. Um. You missquoted, that wasn't me who said that. -- 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.
Re: [whatwg] Popular Background Geolocation question on StackOverflow
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.
Re: [whatwg] Popular Background Geolocation question on StackOverflow
[Philipp Serafin :] > If this problem is specific to the "track a route" use-case, and the > use-case is sufficiently widespread, would a dedicated "route recording" > API make sense? > > 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. Playing audio is already a special case; the tab with the active element will almost certainly not have its setTimeout's honored until it comes back to foreground. But the "ended" event will get to run, at least long enough to move to the next track. In fact, it can XHR and get to run/play-next on the completion. (But wait, on slower tablets Firefox doesn't allow quite enough CPU to keep the background mp3 playing. Oops.) Or think about the iterations in the space of downloads (XHR, service worker background fetch, background sync). 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? $0.02, Andy Valencia
Re: [whatwg] Popular Background Geolocation question on StackOverflow
On 2018-03-24 21:15, Philipp Serafin wrote:
If this problem is specific to the "track a route" use-case, and the
use-case is sufficiently widespread, would a dedicated "route recording"
API make sense?
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?
It would also provide some hooks for privacy controls: A browser could show
a status indicator whenever it's in "GPS recording" mode. It could also
notify the user when it's about to push the recorded route to the page and
possibly even show the route for confirmation.
I certainly see the charm and practicality in a webapp asking the client
(browser) to start logging GPS coords (it must be user initiated at some
point though, like a button/link click).
And then the same when stopping it.
A _start function and a _stop function and a _get function would be all
that is needed.
The _stop function should be self explanatory. The _start function would
allow a argument of milliseconds (or is seconds enough granularity?),
which specifies the interval the client should use to record the current
GPS and other info.
The _get function of such a API would just return a JSON array of GPS
objects, with cords, height and timestamp of the reading, with future
expandability for including stats like pressure and moisture and
temperature (can't think of anything else).
For a cyclist/runner/driver/boater the coords might be useful (to get
distance and route traveled). For a camper or woodsman or farmer or who
knows what else the moisture and temperature and pressure and elevation
may be valuable (the GPS coords would be almost identical for each
reading though).
I'm not sure if this would fit under a geolocation API though, perhaps
more under a environmental API (where GPS/elevation is just one of many
data).
Since the user explicitly (or implicitly) press start there is no need
to ask permission.
But there should be a possibility to ask for site permisssion and have
the webapp autostart, this would allow to run the wwebapp in a browser
24/7 and have it send "live" data to a server. This could make a
smartphone a temporary weather station (a smartphone could have a
external "weather sensor box" connected for example, providing the
sensor input for this API, the browser would just see it as OS provided
sensor data).
Sure a Raspberry Pi or some other IOT with some scripting can do this
better, but just plopping a smart device to a large battery pack or
mains power and leaving it over the night sending live data to a server
could be useful. Hundreds if not thousands of these round the world
could supplement weather research/sites with that data.
I'd suggest this as a way to detect if such a API is available
if ("environment" in navigator) {
/* environment API is available */
} else {
/* environment API IS NOT available */
}
It would really need to be it's own thing instead of adding to the
geolocation, there should be no issues with both coexisting.
--
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.
Re: [whatwg] Popular Background Geolocation question on StackOverflow
If this problem is specific to the "track a route" use-case, and the use-case is sufficiently widespread, would a dedicated "route recording" API make sense? 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. This would allow the browser to record locations changes with reasonably accuracy *without* waking up service workers. It would also provide some hooks for privacy controls: A browser could show a status indicator whenever it's in "GPS recording" mode. It could also notify the user when it's about to push the recorded route to the page and possibly even show the route for confirmation. Roger Hågensen schrieb am Sa., 24. März 2018, 19:49: > On 2018-03-19 00:25, Richard Maher wrote: > > FYI This question on StackOverflow has now had over 1000 views: - > > > https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain > > > > Please explain why nothing is happening. > It has a accepted solution. > > But one key issue is that browers throttle down or even pause inactive > windows/background tabs. > Partly blame digital currency mining for this, blame the rest on bad > programmers running full tilt when they don't need to and DDOS trojans > for the rest. > > I haven't looked this up, but is there a way to ask the user for > permission to run as a background app without performance restrictions? > That is the only way I forsee this working across all browsers. > > > > > > -- > 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. >
Re: [whatwg] rendering for case min == max
On 2018-03-19 12:49, Anne van Kesteren wrote: On Mon, Mar 19, 2018 at 11:13 AM, Mikko Rantalainen wrote: The spec should specify one way or the other for this corner case. Agreed, we're tracking this in https://github.com/whatwg/html/issues/3520. If anyone would like to help clarify the prose in the form of a pull request or wants to make a strong case for Firefox's behavior, that'd be much appreciated. Is it possible the Firefox devs assumes that 0,0,0 infers this to be a "unknown" progress state? On Windows UI this tends to be shown as a a full but "pulsing" progress bar, in a looping animation. But I've seen UI design that also fills up the progress then clears it, in a looping animation. Thouigh one could easily "animate" this via just setting the values, so even if 0,0,0 was speced to always show nothing one could still do the "unknown"! behaviour. Personally I think 0,0,0 should not only be empty but the actual progress bar itself should not be drawn as it's in a non-state if you know what I mean. Which probably will be changed by some javascript moments later. Treat 0,0,0 as it being there but just non-visible maybe? Although I'm almost tempted to say that 0,0,0 should throw a warning in the dev console log that a valid range must be set and that the value must be within (inclusive) that range. -- 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.
Re: [whatwg] Popular Background Geolocation question on StackOverflow
On 2018-03-19 00:25, Richard Maher wrote: FYI This question on StackOverflow has now had over 1000 views: - https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain Please explain why nothing is happening. It has a accepted solution. But one key issue is that browers throttle down or even pause inactive windows/background tabs. Partly blame digital currency mining for this, blame the rest on bad programmers running full tilt when they don't need to and DDOS trojans for the rest. I haven't looked this up, but is there a way to ask the user for permission to run as a background app without performance restrictions? That is the only way I forsee this working across all browsers. -- 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.
