Re: [whatwg] Expected ratio of ServiceWorker instances to Geolocation Updates

[Richard Maher]

Please be advised that, as promised/threatened, I have added the Trip
Summary page and you can now map and replay your trip on Google Maps.

The new version of the code is at the same link
https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU

Most important design/proposed-specification change is that TravelManager
subscription should now be Client specific. The TravelEvent must contain
the intended Client.id (TravelEvent.source.id). This means that the UA must
monitor and filter GeoLocation updates per client. I have also added new
demo functionality such as a Trip Summary that is displayed when you press
the "Arrive" button. The trip can also be replayed onto Google Maps by
pressing "Map Trip" or "Replay". If the last and next geolocation updates
for the trip are both visible in the Map window then smooth Marker movement
is achieved via CSS transitions.

*PLEASE* help Background GeoLocation get up and help Web Apps compete with
Native Apps!

If there is something wrong with my TravelManager solution design then let
me know. Tear holes in it!

On Thu, Jul 20, 2017 at 6:36 PM, Richard Maher 
wrote:

> For some time I've been arguing with W3C/IETF (and anyone else who'd
> engage) that ServiceWorkers are the ideal platform to host the Background
> Geolocation functionality that Ultimate Web Apps need in order to compete
> on a level playing field with Native Apps. The sticking point is usually
> the fleeting nature of a ServiceWorkers' lifespan. I have always argued
> that it would be madness to kill them immediately and most implementations
> seem to agree. (Firefox being the most aggressive at 30secs see Bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1378587 this behaviour
> prevails even with heaps of CPU/Memory)
>
> Anyway, in order to prove that I am right, and the likes of Jake Archibald
> are very much mistaken, I wrote a little Web App, Source code can be found
> here: https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU
> (There is a aaa_readme.txt) All code is documented full and contains
> meaningful/witty variable names.
>
> Now it still needs a bit of work to provide a trip summary page and map
> the trip on Google maps but I think you'll get the idea and most
> importantly see the real world, actual, demonstrable relationship between
> Service Worker Instances and Geolocation updates? (I wanted to get it out
> before the Europeans disappeared for August
>
> So have I done something stupid here? Am I imagining that I only get a new
> Service worker instance when I'm stuck at the lights for an extended period
> on the way home and position updates are nowhere to be seen? Are my coding
> skills lamentable and testing skills non-existent?
>
> If not, then I have no idea why Web Apps are not allowed to satisfy these
> legitimate and very desirable user requirements. Sure, we'll get
> user-empowerment, permissions, and discovery right but let's get on with
> it? The TravelManagerPolyfill.js file is nearly all UA developers have to
> do!
>
> Q: Have I understood the ServiceWorker architecture correctly and
> implemented a valid heuristic interrogation of ServiceWorker instantiation
> over time?
>

[whatwg] Expected ratio of ServiceWorker instances to Geolocation Updates

[Richard Maher]

For some time I've been arguing with W3C/IETF (and anyone else who'd
engage) that ServiceWorkers are the ideal platform to host the Background
Geolocation functionality that Ultimate Web Apps need in order to compete
on a level playing field with Native Apps. The sticking point is usually
the fleeting nature of a ServiceWorkers' lifespan. I have always argued
that it would be madness to kill them immediately and most implementations
seem to agree. (Firefox being the most aggressive at 30secs see Bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1378587 this behaviour
prevails even with heaps of CPU/Memory)

Anyway, in order to prove that I am right, and the likes of Jake Archibald
are very much mistaken, I wrote a little Web App, Source code can be found
here: https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU (There
is a aaa_readme.txt) All code is documented full and contains
meaningful/witty variable names.

Now it still needs a bit of work to provide a trip summary page and map the
trip on Google maps but I think you'll get the idea and most importantly
see the real world, actual, demonstrable relationship between Service
Worker Instances and Geolocation updates? (I wanted to get it out before
the Europeans disappeared for August

So have I done something stupid here? Am I imagining that I only get a new
Service worker instance when I'm stuck at the lights for an extended period
on the way home and position updates are nowhere to be seen? Are my coding
skills lamentable and testing skills non-existent?

If not, then I have no idea why Web Apps are not allowed to satisfy these
legitimate and very desirable user requirements. Sure, we'll get
user-empowerment, permissions, and discovery right but let's get on with
it? The TravelManagerPolyfill.js file is nearly all UA developers have to
do!

Q: Have I understood the ServiceWorker architecture correctly and
implemented a valid heuristic interrogation of ServiceWorker instantiation
over time?