Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

On 2018-03-25 09:08, Richard Maher wrote:
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.


There is no "going to be" Roger. You are not embarking on a green-field 
development or brain-storming "The Web". We are where we are. I don't 
care if people want to change things but it is DEFINITELY out-of-scope 
for the Background Geolocation implementation.


I was a unaware you where the moderator of the Background Geolocation 
specs or similar. In that case my apologies, I had no intention of 
pushing things into the specs that do not belong there (it's bad enough 
in politics).


But I don't understand what you mean by "We are where we are" or why you 
are against brain storming and I had to lookup the greenfield term but I 
am unsure if you mean untapped market, new software projects, 
undeveloped land or if you are referring to an area in Manchester (yes 
I'm being an asshat on that last one).


I'm also unsure if you are being sarcastic or are actually trying to 
dictate what I should or should not do. If you are upset that things 
veered off topic then I'm sorry about that.


To me it looks like you want a commercial backend solution for Uber or 
Dominos or similar (not end users). Surely these can run apps on tablets 
or smartphones? Browsers are pretty good but for operational software 
you want reliability and a consumer browser despite the amazing efforts 
of the developers so far is not that stable yet. If "always on in the 
background" is key to a business then a OS run background service is 
exactly what is needed.


If you need certain functionality implemented and your project is 
waiting on this then I suggest you make a OS native app instead before 
your competitors sale past you.


Looking through the WHATWG history I do not like what I see so I'm going 
to stop communicating regarding this topic, and most likely future 
topics by you, you come across as excessively abrasive and I'd rather 
not have to deal with that. You've said in the past that you felt you 
have been stifled or censored by others, well now you have succeeded in 
stifling me. I'm having difficulties communicating with you, I can't 
even imagine trying to work on code or standards implementations with you.



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

2018-03-25 6:29 GMT+02:00, Roger Hågensen :
> 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 :

[...]

>> 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.)

Re: [whatwg] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

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

[Roger Hågensen]

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

[Roger Hågensen]

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

[Andy Valencia]

[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

[Roger Hågensen]

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

[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.

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] Popular Background Geolocation question on StackOverflow

[Roger Hågensen]

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.