Path: csiph.com!news.redatomik.org!aioe.org!.POSTED!not-for-mail
From: Richard Maher <maher_rjSPAMLESS@hotmail.com>
Newsgroups: comp.os.vms,comp.lang.javascript,comp.lang.java.programmer
Subject: Re: Expected ratio of ServiceWorker instances to Geolocation Updates
Date: Sat, 22 Jul 2017 07:55:35 +0800
Organization: Aioe.org NNTP Server
Lines: 78
Message-ID: <oku49t$mna$1@gioia.aioe.org>
References: <okq087$o1c$1@gioia.aioe.org>
NNTP-Posting-Host: jD1JqOO5t9i/GOBshLHVdQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
X-Notice: Filtered by postfilter v. 0.8.2
Content-Language: en-US
Xref: csiph.com comp.os.vms:69183 comp.lang.javascript:33605 comp.lang.java.programmer:36979

On 20-Jul-17 6:21 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)
> 
> 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?


For those wanting to know where the Java, VMS, and C# relevance is, you 
need to look at the Service Worker code echo.js, in particular: -

/*
  * Even if there are no active client windows we still let Starship
  * Control know where we are so thay can let us know (notify us) of a
  * GeoFence we've just traversed of a bargain to be had at that pub over
  * there.
  */
	function tellFleetManager(payLoad)
	{
		return new Promise((resolve, reject) =>
		{
		fetch(FLEET_MANAGER, {
			method: "POST",
			credentials: 'same-origin',
			headers: {
				'Content-Type': 'application/json'
			},
			body: payLoad
		}).then(response =>
			{
				if (response.ok) {
					resolve(response.json())
				} else {
					var error = new Error(response.statusText)
					error.response = response
					throw error;
				}
			}).catch(function(error) {
				console.log('Fleet request failed', error)
				reject(error);
				});
		})
	}	

This code allows the fleet management C#/Java server to track all 
trucks, pizzas, ski-buddies and plot them as a whole.