New Service Worker Event from GeoLocation

[Richard Maher]

WRT the Service Worker specification can I please request the inclusion of
a new event?

onTravel/Move/Position/Location/WhateverIsAppropriate.

The positionManager subscription should allow one to specify min distance
and/or time between GPS updates but the firing of this event must be
capable of re-instantiating a previously-terminated Service Worker.

May I also please draw your attention to two see-change posts currently
active in the W3C forums: -

https://github.com/w3c/geofencing-api/issues/25
https://github.com/slightlyoff/ServiceWorker/issues/745

"GeoLocation in ServiceWorkers" you know it makes sense?

Cheers Richard Maher

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

[Richard Maher]

Look I %100 acknowledge the problem(s) @martinthomson highlights, and the
need to prevent abuse from the black hats. All I’m saying is let’s work the
problem rather than simply rocking in the foetal position, or worse,
concocting artificial and exaggerated speed-humps on the release path of
much needed functionality.



On the plus side: -



1)   User permission must be granted before GPS is accessible.

2)   While GPS is being watched, even in background, the
circles/ripples icon cue is visible to user on the device.

3)   The underlying Service Worker architecture mandates the use of
secure/authenticated httpS communication.

4)   The user can be 100% sure tracking is off by simply closing
the browser on their device.



I personally think the above is enough, but for the sake of argument, does
anyone have thoughts on how access may be further governed?



1)   Only permit background/service-worker GPS access if the Web
App is installed/home-screened?

2)   If a single GPS permission will cover both background and
foreground access, then put a link on the toast to the Faustian details?

3)   Use a new icon, perhaps an eye or a doughnutted version of the
current GPS ripples? Pulse the icon?



Similar conundrums so that Service Worker GPS is not singled out unfairly: -



1)   Firefox currently continues to process watchPosition events in
background

2)   All browsers except IE and Chrome continue to watchPosition
when phone is locked but browser tab in foreground.

3)   The proposed WAKE-LOCK and CPU-LOCK will backdoor user-tracking

4)   The proposed GeoFence API, as it stands, will be another
backdoor to user tracking

5)   Native Apps can do this with impunity

6)   Push Messages must be required to trigger a notification so as
not to be silent/stealthy.

7)   Geofencing is still tracking! Knowing when my next victim
leaves their house each Tuesday is still an intrusive invasion of one’s
privacy if it has not been sanctioned. Surely the degree of “badness” is
not the issue here?



Also, can I list just the proposed restrictions on the GeoFence API that I
know about: -

1)   Maximum number of geofences

2)   Only circular geofences

3)   Maximum area of a geofence

4)   Minimum area of a geofence

5)   (Soon to be?) Cannot create a geofence in a service worker.

6)   Fat Client, heuristically-challenged, localized, geofence
processing

7)   A technology born of a time when Java was king and batteries
were the size of a brick and lasted just 2 hours.



Are these design smells not beginning to make people think twice?



Finally, to address some of Martin’s comments directly: -



> Tracking the user in the background is highly likely to be a case of a
site acting poorly.



Unsubstantiated, conjecture, hearsay, prejudice, and FUD :-(

A plethora of valid business cases and user-requirements have been
portrayed for all who are willing to see. We must find a way to satisfy
these legitimate requirements whilst fire-walling against malicious intent.



> I want to ensure that the user remains in control;



Here we are in violent agreement! See the “plus side”. How more empowered
can the user be?



Look, I enforce my right to privacy more than most, I can assure you! I am
not on FacePlant, LinkedIn, etc. I do not use my real photo on the net. I
pay cash everywhere I can, and wish I could stop my card having Tap-n-Go.
But @MulderAndScully I do not wear a tin-foil hat.



> I don't believe that asking users for permission is sufficient to that
end for some types of features. This is one of them.



Can you please give me examples of one or two other features that you felt
failed your test? How did you get on overturning the SpeechRecognition API
and access to that microphone?



The Service Worker developers must love all their children equally! Just
because the blue-eyed boy of GeoFencing turned out to be the milkman’s
mongrel doesn’t mean that your GeoLocation Cinderella can’t go to the ball.



Let’s get on with it – please.

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

[Richard Maher]

I found a very interesting, and inspiring quote today that I'd like to
share with you: -

https://twitter.com/jaffathecake
Googler. "I want the web to do everything native can, and fast."

So  can anyone here explain to me how that precludes device/user tracking?
Or how HTML5 Web Apps can not be available today with the same
functionality as Uber, Domino's, GrindR, FaceBook, tomtom?

What the hell are you waiting for?

Here's a couple more platitudes to get you through to the next F2F plenary
junket: -

https://twitter.com/jaffathecake/status/633621917547778048

"The web should look to increase its advantages while reducing its
disadvantages. Native is doing this too. If the web stops, it dies."

"The web doesn't need to be better than native at everything, it just needs
to be close enough that the gap in certain areas doesn't matter."

Re: [geolocation] New Working Group Technical Report - Background GPS

[Richard Maher]

Addendum (Sorry)

Other Options: -
4) When the device goes to sleep when a Web App is still watching GPS, or
simply backgrounds or minimizes a device-tracker, it should make a sound
and or vibrate as a non-visual cue that tracking is ongoing?
5) When a device is reawakened or a device-tracking app is brought back to
the foreground, then a notification must be sent to the user "This App
continued to monitor your location in the background". The "Settings" icon
on the message could facilitate "Prevent this app from tracking in the
background" Forever/Just once.
6) Like the Push API the default must be DO NOT track in the background. If
the user chooses the individual APP settings then they can turn it on?

On Wed, Feb 17, 2016 at 9:42 AM, Richard Maher <mahe...@googlemail.com>
wrote:

> Hi,
>
> I have no experience with how a W3C standard gets off the ground, or an
> existing standard gets modified, but it would appear that a Working Group
> Technical Report is required. Either way, none of the browser manufacturers
> seem keen on implementing this functionality without W3C involvement so I
> implore you to look at my proposal to enhance to the GEOSPATIAL and
> JAVASCRIPT APIs standards for background device-tracking.
>
> NB. These are Apples and the proposed GeoFencing API are Oranges. I am
> happy to explain that claim at anytime.
>
> If someone will volunteer to pick this idea up and run with it the HTML5
> Web App world will be a much better place!
>
> Solution: -
>
> I propose a new W3C standard implementing a "TravelManager" and exposing the 
> interface to ServiceWorkers. This interface would be very similar to the 
> existing PushManager interface. E.g. ServiceWorkerRegistration.travelManager 
> (getSubscription(), permissionState(), subscribe())
>
> The subscribe() method with take options such as (minMsecs/metersl between 
> position updates, accuracy, etc)
>
> A new ServiceWorker "Travel" event will be created. The UserAgent must be 
> able to re-instantiate a previously terminated ServiceWorker on the strength 
> of this event.
>
> Power consumption mitigation: -
> 1) The Web App is allowed to sleep as it does now ABSOLUTELY NO 
> requestWakeLock("gps") required.
> 2) Although Android mandates that it "can" terminate a browser at any time, a 
> well resourced device need not terminate Service Workers as soon as the event 
> Loop is empty. This allows a single SW to service many GPS readings an 
> forward them to a server in a single instance/lifetime.
> 2) If no browser/user-agent instance is active then it should NOT be run-up 
> in order to accept the  GPS. Thus the user is always capable of guaranteeing 
> an end to tracking by killing the browser.
>
> User-empowerment, transparency, and governance: -
> 1) User permission must be explicitly granted before GPS is accessible.
> 2) While GPS is being watched, even in background, the circles/ripples icon 
> cue is visible to user on the device.
> 3) The underlying Service Worker architecture mandates the use of 
> secure/authenticated httpS communication.
> 4) The user can be 100% sure tracking is off by simply closing the browser on 
> their device.
> 5) The manifest-resident gcm_sender_id (Google Project Id) can be 
> revoked/voided if a site is behaving badly
>
> Other Options: -
> 1) Only permit background/service-worker GPS access if the Web App is 
> installed/home-screened?
> 2) If a single GPS permission will cover both background and foreground 
> access, then put a link on the permission-toast pointing to the Faustian 
> details?
> 3) Use a new icon, perhaps an eye or a doughnutted version of the current GPS 
> ripples? Pulse the icon?
>
> Similar conundrums so that Service Worker GPS is not singled out unfairly: -
>
> 1) Firefox currently continues to process watchPosition events in background
> 2) All browsers except IE and Chrome continue to watchPosition when phone is 
> locked but browser tab in foreground.
> 3) The proposed WAKE-LOCK and CPU-LOCK will backdoor user-tracking
> 4) The proposed GeoFence API, as it stands, will be another backdoor to user 
> tracking
> 5) Native Apps can do this with impunity
> 6) Push Messages must be required to trigger a notification so as not to be 
> silent/stealthy.
> 7) Geofencing is still tracking! Knowing when my next victim leaves their 
> house each Tuesday is still an intrusive invasion of one’s privacy if it has 
> not been sanctioned. Surely the degree of “badness” is not the issue here?
> 8) Speech synthesis API and microphone access
>
> PS. Mozilla is also floundering: 
> -https://bugzilla.mozilla.org/show_bug.cgi?id=1216148https://bugzilla.mozilla.org/show_bug.cgi?id=784505
>
> Thanks for listening.
>
> Cheers Richard Maher
>
>
>
>

[geolocation] New Working Group Technical Report - Background GPS

[Richard Maher]

Hi,

I have no experience with how a W3C standard gets off the ground, or an
existing standard gets modified, but it would appear that a Working Group
Technical Report is required. Either way, none of the browser manufacturers
seem keen on implementing this functionality without W3C involvement so I
implore you to look at my proposal to enhance to the GEOSPATIAL and
JAVASCRIPT APIs standards for background device-tracking.

NB. These are Apples and the proposed GeoFencing API are Oranges. I am
happy to explain that claim at anytime.

If someone will volunteer to pick this idea up and run with it the HTML5
Web App world will be a much better place!

Solution: -

I propose a new W3C standard implementing a "TravelManager" and
exposing the interface to ServiceWorkers. This interface would be very
similar to the existing PushManager interface. E.g.
ServiceWorkerRegistration.travelManager (getSubscription(),
permissionState(), subscribe())

The subscribe() method with take options such as (minMsecs/metersl
between position updates, accuracy, etc)

A new ServiceWorker "Travel" event will be created. The UserAgent must
be able to re-instantiate a previously terminated ServiceWorker on the
strength of this event.

Power consumption mitigation: -
1) The Web App is allowed to sleep as it does now ABSOLUTELY NO
requestWakeLock("gps") required.
2) Although Android mandates that it "can" terminate a browser at any
time, a well resourced device need not terminate Service Workers as
soon as the event Loop is empty. This allows a single SW to service
many GPS readings an forward them to a server in a single
instance/lifetime.
2) If no browser/user-agent instance is active then it should NOT be
run-up in order to accept the  GPS. Thus the user is always capable of
guaranteeing an end to tracking by killing the browser.

User-empowerment, transparency, and governance: -
1) User permission must be explicitly granted before GPS is accessible.
2) While GPS is being watched, even in background, the circles/ripples
icon cue is visible to user on the device.
3) The underlying Service Worker architecture mandates the use of
secure/authenticated httpS communication.
4) The user can be 100% sure tracking is off by simply closing the
browser on their device.
5) The manifest-resident gcm_sender_id (Google Project Id) can be
revoked/voided if a site is behaving badly

Other Options: -
1) Only permit background/service-worker GPS access if the Web App is
installed/home-screened?
2) If a single GPS permission will cover both background and
foreground access, then put a link on the permission-toast pointing to
the Faustian details?
3) Use a new icon, perhaps an eye or a doughnutted version of the
current GPS ripples? Pulse the icon?

Similar conundrums so that Service Worker GPS is not singled out unfairly: -

1) Firefox currently continues to process watchPosition events in background
2) All browsers except IE and Chrome continue to watchPosition when
phone is locked but browser tab in foreground.
3) The proposed WAKE-LOCK and CPU-LOCK will backdoor user-tracking
4) The proposed GeoFence API, as it stands, will be another backdoor
to user tracking
5) Native Apps can do this with impunity
6) Push Messages must be required to trigger a notification so as not
to be silent/stealthy.
7) Geofencing is still tracking! Knowing when my next victim leaves
their house each Tuesday is still an intrusive invasion of one’s
privacy if it has not been sanctioned. Surely the degree of “badness”
is not the issue here?
8) Speech synthesis API and microphone access

PS. Mozilla is also floundering:
-https://bugzilla.mozilla.org/show_bug.cgi?id=1216148https://bugzilla.mozilla.org/show_bug.cgi?id=784505

Thanks for listening.

Cheers Richard Maher

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

[Richard Maher]

@martinthomson 

I hate to make this a point of jurisdiction, but I think that this is a
discussion that needs to be had in the geolocation working group.

I've been careful to avoid any demarcation issues by always involving the
Service Worker AND GeoLocation communities. My lobbying has centered on: -

Forums:
https://github.com/slightlyoff/ServiceWorker/issues/745

https://github.com/w3c/geofencing-api/issues/25


Mailing Lists:
public-webapps@w3.org
public-geolocat...@w3.org

If there are better forums then please let me know.

Having said that, I am becoming more and more convinced that this is a
Service Worker issue. The following is what I believe is required to make
this work: -

ServiceWorkerRegistration.travelManager (getSubscription(),
permissionState(), subscribe())
The subscribe() method with take options such as (minMsecs/metersl between
position updates, accuracy, etc)

A new ServiceWorker "Travel" event will be created. The UserAgent must be
able to re-instantiate a previously terminated ServiceWorker on the
strength of this event.

One GeoLocation watcher per UserAgent sounds battery-friendly to me!

I'm very nervous when someone saves their hands when it comes to the
privacy story. The web has thus far had a great accountability story and
adding the ability to track someone when they aren't visiting your site is
one capability that could easily undermine all the good work we've done.
I'd want to see a clear plan for how a user is able to remain in control to
be even remotely comfortable that watchPosition could be exposed.

God gave us valium and SSRIs for just such occasions. Either way please
don't FUD a technical forum with tales of "There be dragons".

Users are running a WebApp and NOT "visiting your site". Permissions are
there for just such a requirement. BTW I tested Firefox last night and it
is the only browser that DOES continue to track you when the browser is in
the background.

But can I ask where have you articulated your fears about WAKE-LOCK and
CPU-LOCK back-dooring user-tracking functionality? What about the new
GeoFence API? If I throw a 5m GeoFence around my current location and get a
"leave" event then surely I can just drop that geofence and recreate
another around my new current location. What is that if not user-tracking?

Most importantly, can I stress that this is a user REQUIREMENT and not an
IMPOSITION! Ask all the permission questions you want but this simply has
to happen.

Re: HTML5's Offline-first Council of Trent

[Richard Maher]

> An even more powerful (but also ignored possibility) would be COMBINING
the power
of the Web and App worlds instead of fighting religious wars ("the Web is
great"),
where there are no winners, only lost opportunities.

That's what plugins were for wan't it? And I still cry every night over the
death of Applets :-(
(A single mutliplexed (static) TCP/IP full-duplex connection per
user-agent!)

> It gets worse...if you are the Web tech leader then you are apparently
free taking
this "shortcut" (some people would rather characterize this as an
intelligent use
of available resources and competences), and get away with it as well:
https://github.com/w3c/webpayments/issues/42#issuecomment-166705416

C'mon Anders, do you blame them?

Faced with the intractability, self-interest, and narcissism  surrounding
the IOC^h^h^hW3C Gordian knot, are you really surprised that  someone
owning the implementation will pull out their sword and opt for results
over process?


On Thu, Mar 17, 2016 at 1:34 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On 2016-03-17 06:00, Richard Maher wrote:
>
>> Hi Patrick (Congratulations on today) Technical Point follows: -
>>
>> On a merit-based resource allocation basis, the two most fundamental,
>> essential,
>>
> > and absolutely necessary HTML5 Web-App feature enhancements are: -
>
>>
>> 1) Background GPS device/user tracking support
>> 2) Push API 1:M broadcast capability
>>
>> These are enabling technologies that will catapult HTML5 Web Apps into the
>>
> > Native App heartland and single-handedly alter the development-tool and
> deployment
> > strategies for Mobile App vendors around the world.
>
> An even more powerful (but also ignored possibility) would be COMBINING
> the power
> of the Web and App worlds instead of fighting religious wars ("the Web is
> great"),
> where there are no winners, only lost opportunities.
>
> It gets worse...if you are the Web tech leader then you are apparently
> free taking
> this "shortcut" (some people would rather characterize this as an
> intelligent use
> of available resources and competences), and get away with it as well:
> https://github.com/w3c/webpayments/issues/42#issuecomment-166705416
>
> Anders
>
>
>> The reason these features do not appear on the W3C horizon is that they
>> show-case online-first and are anathema to the Offline-First Mafia that is
>> currently setting the agenda and feathering its own nest.
>>
>> Technically, I have to admit to having absolutely no idea how a W3C
>> performance review would be conducted or how ROI on a given contributor's
>> input could be measured. I am a simple man who just needs a couple more
>> tools in the box in order to deliver the killer Web Apps my users are
>> begging for.
>>
>> Where I come from, and certainly from my experience in London finance,
>> it's all about getting the job done! You can have two heads and be the most
>> obnoxious Maher in the world but you're paid to do a job and get around the
>> Sir Humphrey Appleby speed humps on the road the progress in order to do it.
>>
>> I'm not here to make friends or see how many followers I can get on
>> Twitter, and I apologize for being the only one without an original selfie
>> of myself looking wistfully off camera, but I'm motivated by results and
>> not married to the process.
>>
>> HTML5 - Web Apps "The journey is *NOT* the destination!
>>
>> On Wed, Mar 16, 2016 at 5:58 PM, Patrick H. Lauke <re...@splintered.co.uk
>> <mailto:re...@splintered.co.uk>> wrote:
>>
>> On 16/03/2016 04:46, Richard Maher wrote:
>> ...
>>
>> Anyway, if the decorum police will agree to stay their truncheons
>> for a
>> moment longer and indulge my use of satire, parody, and metaphor,
>> in
>> making an extremely valid technical point,
>>
>> ...
>>
>> Or you could just make your valid technical point, without resorting
>> to your sarcastic tone which, frankly, is quite grating and is doing you no
>> favors in getting at least some of the readership on this  list to even
>> want to engage in your argument.
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk <http://www.splintered.co.uk> |
>> https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>>
>

HTML5's Offline-first Council of Trent

[Richard Maher]

I was going to post this as a reply to #844
 (*) but this
topic is a far greater and more of an all-encompassing issue than any
single thread can serve.

We (all HTML5 Web-App developers) desperately need a schism from the
heretical forces of "Offline First" and the Spartan, austere, featureless
world, of Web-App minimalism!

If you want to hamstring yourselves and live a primitive
pre-telecommunications lifestyle, or something more akin to life post
Road-Warrior Apocalypse, then good for you; just stop white-anting people
who wish to take full advantage of modern technology!

For most "cashed-up" consumers, Lack of Connectivity is the exception an
NOT the norm. (And I live in the most isolated capital city in the world so
cop that!) Sure we'll failback and degrade gracefully but we WILL NOT
target the bean-tins-and-string deployment option.

Your Client-Based GeoFences are a joke :-( Your willingness, nay
preference, to serve up stale, outdated data, is an exercise in
self-flagellation that only a fellow sicko could understand.

But let us wicked technologists not sway you from your
life-was-meant-to-be-hard, God-would've-given-us-wings fanaticism. All we
want is a fair share of the Chrome, Mozilla, Opera, and Safari development
budgets for expanding the Feature List rather than censoring it.


(*) The reason I was quoting that thread is that it used to contain the
following: -


 > Although we're using a timeout, this approach still suffers from being
online-first. A better approach is offline-first
https://jakearchibald.com/2014/offline-cookbook/#cache-then-network
Drives me absolutely insane :-(

Re: HTML5's Offline-first Council of Trent

[Richard Maher]

Hi Patrick (Congratulations on today) Technical Point follows: -

On a merit-based resource allocation basis, the two most fundamental,
essential, and absolutely necessary HTML5 Web-App feature enhancements are:
-

1) Background GPS device/user tracking support
2) Push API 1:M broadcast capability

These are enabling technologies that will catapult HTML5 Web Apps into the
Native App heartland and single-handedly alter the development-tool and
deployment strategies for Mobile App vendors around the world.

The reason these features do not appear on the W3C horizon is that they
show-case online-first and are anathema to the Offline-First Mafia that is
currently setting the agenda and feathering its own nest.

Technically, I have to admit to having absolutely no idea how a W3C
performance review would be conducted or how ROI on a given contributor's
input could be measured. I am a simple man who just needs a couple more
tools in the box in order to deliver the killer Web Apps my users are
begging for.

Where I come from, and certainly from my experience in London finance, it's
all about getting the job done! You can have two heads and be the most
obnoxious Maher in the world but you're paid to do a job and get around the
Sir Humphrey Appleby speed humps on the road the progress in order to do
it.

I'm not here to make friends or see how many followers I can get on
Twitter, and I apologize for being the only one without an original selfie
of myself looking wistfully off camera, but I'm motivated by results and
not married to the process.

HTML5 - Web Apps "The journey is *NOT* the destination!

On Wed, Mar 16, 2016 at 5:58 PM, Patrick H. Lauke <re...@splintered.co.uk>
wrote:

> On 16/03/2016 04:46, Richard Maher wrote:
> ...
>
>> Anyway, if the decorum police will agree to stay their truncheons for a
>> moment longer and indulge my use of satire, parody, and metaphor, in
>> making an extremely valid technical point,
>>
> ...
>
> Or you could just make your valid technical point, without resorting to
> your sarcastic tone which, frankly, is quite grating and is doing you no
> favors in getting at least some of the readership on this  list to even
> want to engage in your argument.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>

Re: HTML5's Offline-first Council of Trent

[Richard Maher]

Look Jake, your entire argument is premised on the abstract notion that “cached
data is often fine”. Allow me to respond with an equally unquantifiable
“EXCEPT WHEN IT BLOODY ISN’T”.



I’ve been cutting code for over 30 years and am very familiar with
scenarios where cached data is appropriate and if history is any guide it
tells us that server-level caching is the most effective (especially with
sophistication levels as high as Oracle’s cluster-wide Cache-Fusion). The
Fat-Client pattern came and went 20 years ago as far as I’m concerned but
if you, and others at W3C, are happy to breathe new life into the IBM 3270
[2] architecture by re-implementing it on the Web, then more power to you.
Those like myself who have gotten used to features such a server-hosted
character-by-character predictive-text, real-time banking, and trading, are
loathed to take such an enormous step backwards. You appear to have a
marvelous solution, but I and many others are not experiencing your
perceived problem(s).



The very real problem we are experiencing is the disproportionate resource
and funding allocation from browser vendors toward infrastructure and
functionality targeted at social-media. Not everything is Twitter and Email
for Pete’s sake or, for that matter, an RSS aggregation of this morning’s
newspapers.



Give us background GPS, give us some sort of broadcast/multi-cast Push API
capability without 1:1 notifications, just give us the tools to compete
with native apps and we’ll do the rest!



Anyway, if the decorum police will agree to stay their truncheons for a
moment longer and indulge my use of satire, parody, and metaphor, in making
an extremely valid technical point, I’d like to introduce to you the latest
Web-App offering from HTML5 Horse-First Laboratories ™ [1]: -



*The Bud Fox Day-Trader App*



The true beauty of this Web App is that it doesn’t matter one iota what
time-zone you’re in as you can always buy and sell at a price that suits
your cache$ [4]



Wall Street may be closed, you could be going through the Channel Tunnel,
or you could simply be on the dark side of the moon, but BF Day-Trader will
let you buy or sell virtually straight from your stock portfolio!



*“But what if the current stock price is different to what I’m seeing and
trading in?” *



This is where Day-Trader shines above all the Native Apps that have to
submit to the laws of physics as well as the governance of the Securities
and Exchange Commission. Your trades don’t happen in real-time either! A
background-sync job will get around to transmitting your trade to the Stock
Exchange as soon as your network usage limits allow. By then the stock
price could well be what you bid for in the first place anyway. How good is
that!



In the words of our Systems Architect [3] “Close enough is good enough!”.



[1] http://images.clipartpanda.com/amish-clipart-68145_134_w11-14_s_lg.gif

[2] https://en.wikipedia.org/wiki/IBM_3270

[3] http://farm8.static.flickr.com/7278/7852694410_b2d8aa034c.jpg

[4]* Cache$ (Uselessness is relative concept)*



Cache$1 - This is the red-hot highly volatile repository for stocks that
you traded in the last week. Memory consumption is critical so less than
100 stocks are resident here and refresh rates can be almost hourly
depending on network availability.



Cache$2 – Overflow from Cache$1 into perpetuity.



IndexDB – At installation time every stock on the planet and last bid is
copied to your phone. Most DBAs will tell you that the best way to
replicate data is “not at all” but tell that to Thurston Howell III. You
just never know when you’ll have to trade from a deserted island.

On Tue, Mar 15, 2016 at 10:20 PM, Jake Archibald <jaffathec...@gmail.com>
wrote:

> On Tue, 15 Mar 2016 at 12:14 Richard Maher <mahe...@googlemail.com> wrote:
>
>> Your willingness, nay preference, to serve up stale, outdated data, is an
>> exercise in self-flagellation that only a fellow sicko could understand
>>
> This is not the intent in the pattern you quote (
> https://jakearchibald.com/2014/offline-cookbook/#cache-then-network).
>
> The goal is to get cached data on screen then update it. This is because
> cached data is often fine as a first pass.
>
> If I'm going to my messaging app to remind me where I agreed to meet
> someone, cached data is fine. If I'm going to my fitness app to find out
> how long it took me to run two miles last week, cached data is fine. If I'm
> looking up the day for my flight, cached data is fine.
>
> But it doesn't stop there. The network is used, if available, to update
> both the content on the screen (in some non-disruptive way) and in the
> cache.
>
> The benefit of having data locally on the device is you don't need an
> internet connection to get it, if you refuse to show it until a network
> request as settled or timed out, you're throwing away the benefit.
>
> The offline-first patter

Re: HTML5's Offline-first Council of Trent

[Richard Maher]

Nick, while we're waiting for Léonie to lecture you on
participation-criteria,  etiquette, and social competence, let me call on
the late, great, Rodney Dangerfield to proxy my response: -

*Judge Smails*: You have worn out your welcome, sir!
*Czervik*: Is that so? Who made you Pope of this dump?
*Judge Smails*: Bushwood...a "dump"? Well, I'll guarantee you'll never be a
member here!
*Czervik*: Are you kidding? You think I'd join this crummy "snobatorium"?
Why, this whole place sucks!

Now that I think about it I haven't come across a black face here yet, very
few females, and not many Jewish names. Maybe it's still "too soon" for
Reformation references in the W3C Country Club? (BTW. On the FTF-jolly
stakes the IETF Club kicks your arse with Honolulu and Yokohama versus your
Sapporo and Lisbon.)

> Fresh start? If you make a good case, without calling the w3c a mafia,
people might actually engage this more seriously.

Rest assured, I am pulling out of these forums. (I'm just happy to know
that a softer gentler place continues to exist somewhere)

I've found someone who has more credibility and form here and is willing to
take the idea forward. Background GeoLocation was a massive issue before I
pinned my colours too it and is too important to the HTML5 Web App future
to be tarnished by collateral bigotry and prejudice.

But before I go, why do you all look and sound the same?

On Thu, Mar 17, 2016 at 8:49 PM, Nick Dugger <nick.dugg...@gmail.com> wrote:

> Listen, you may not be here to make friends, but if you want to incite
> change, you might try playing nicely. If you just want results, you'll have
> greater success without your sarcasm and superiority complex.
>
> Fresh start? If you make a good case, without calling the w3c a mafia,
> people might actually engage this more seriously. As of right now, I can't
> speak for everyone, but I definitely don't like your tone.
>
> Thanks,
> Nick Dugger
>
> On Thu, Mar 17, 2016, 1:52 AM Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
>
>> On 2016-03-17 07:12, Richard Maher wrote:
>> >> An even more powerful (but also ignored possibility) would be
>> COMBINING the power
>> >> of the Web and App worlds instead of fighting religious wars ("the Web
>> is great"),
>> >> where there are no winners, only lost opportunities.
>> >
>> > That's what plugins were for wan't it? And I still cry every night over
>> the death of Applets :-(
>> > (A single mutliplexed (static) TCP/IP full-duplex connection per
>> user-agent!)
>>
>> Plugins were deprecated which (IMO) was OK since they had serious
>> security issues, what's
>> less satisfactory is removing features without consider some kind of
>> reasonable replacement.
>>
>> Several other somewhat related features are currently also subject to
>> removal/deprecation.
>>
>>
>> >> It gets worse...if you are the Web tech leader then you are apparently
>> free taking
>> >> this "shortcut" (some people would rather characterize this as an
>> intelligent use
>> >> of available resources and competences), and get away with it as well:
>> >> https://github.com/w3c/webpayments/issues/42#issuecomment-166705416
>> >
>> > C'mon Anders, do you blame them?
>>
>> Well, Google more or less wrote the "Grand Plan" and now they are
>> defecting from it,
>> while leaving everybody else with the old (non-working) plan and
>> _severely_disadvantaged_.
>>
>>
>> > Faced with the intractability, self-interest, and narcissism
>> surrounding
>>  > the IOC^h^h^hW3C Gordian knot, are you really surprised that  someone
>> owning
>>  > the implementation will pull out their sword and opt for results over
>> process?
>>
>> I (naively) thought that maybe _somebody_else_ (with more influence than a
>> non-member like me), would be interested in taking a closer look at this
>> powerful capability.  I only seek a constructive discussion on what to do
>> now.
>>
>> Anders
>>
>> >
>> >
>> > On Thu, Mar 17, 2016 at 1:34 PM, Anders Rundgren <
>> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
>> wrote:
>> >
>> > On 2016-03-17 06:00, Richard Maher wrote:
>> >
>> > Hi Patrick (Congratulations on today) Technical Point follows: -
>> >
>> > On a merit-based resource allocation basis, the two most
>> fundamental, essential,
>> >
>> > > and absolutely necessary HTML5 Web-App feature enhancements are: -
>&g