Re: [whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF Success Prevention Depts out of the water!

[Jeffrey Yasskin]

Please follow the WHATWG code of conduct when posting to this list:
https://wiki.whatwg.org/wiki/Code_of_Conduct. In particular, I believe this
message violates:

   - Please be kind and courteous. There's no need to be mean or rude.
   - Respect that people have differences of opinion and that every design
   or implementation choice carries a trade-off and numerous costs. There is
   seldom a right answer.
   - You shall not insult, demean or harass anyone. We interpret the term
   "harassment" as including the definition in the Citizen Code of Conduct
   ; if you have any lack of clarity
   about what might be included in that concept, please read their definition.
   In particular, we don't tolerate behavior that excludes people in socially
   marginalized groups.


Thanks,
Jeffrey

On Tue, Apr 18, 2017 at 4:09 PM, Richard Maher  wrote:

> On Tue, Mar 28, 2017 at 9:30 AM, Roger Hågensen  mailto:rh_wha...@skuldwyrm.no>> wrote:
>
> On 2017-03-27 05:50, Richard Maher wrote:
> Broadcast Messaging and Topic Based subscription is now available to your
> WebApp just like native Apps thanks to FCM.
>
> https://firebase.google.com/docs/cloud-messaging/js/send-multiple
>
> I am absolutely ecstatic about this, as we all should be, and equally
> grateful to FCM for having managed to bypass the recalcitrance and sheer
> bloody-mindedness of spec-authors to provide functionality that everyone
> outside the ivory-towers was begging for.
>
> I thought WhatWG was set up to challenge the delusional elite a la mode de
> HTML5? Why the silence?
>
> Maybe because this is a Google API and cloud service rather than a web
> standard added to Chrome, Firefox, Edge, Safari, Opera, Vivaldi etc? Unless
> I'm missing some important detail here!
>
> Yes it is a Google API. A browser agnostic Google API that runs on Chrome,
> Firefox, Samsung, soon to be Opera, and Edge. Anything that runs
> ServiceWorker and Push. While I would’ve preferred W3C/IETF to see the
> sense and requirement for Topic-based subscriptions and broadcast
> messaging, the Firebase API is from the same stable as other ubiquitous
> APIs such as Google Maps? Analytics? Google+ logon.
>
> Anyway rejoice and be glad as Native Apps have one less stick to beat us
> over the head with. And you Firefox fans are no longer stuck with Mozilla's
> third-rate AutoPush!
>
> I'm not aware of anything called autopush, is this another cloud API?
> Or do you mean https://developer.mozilla.org/en/docs/Web/API/Push_API ?
>
> See:  - https://mozilla-push-service.readthedocs.io/en/latest/
>
>
> Now if we can only get background geolocation with ServiceWorkers nothing
> can stop WebApps: -
> https://github.com/w3c/ServiceWorker/issues/745
>
> Considering I'm coding both native and "HTML5" based "apps" there is far
> more that needs to be improved.
> There is no way to reliably know how much LocalStorage or IndexDB space
> the web app has, trying to access or list files locally in a folder is not
> possible, something as simple as a editable soundboard can't be made if
> it's run locally (via file: protocol).
> While Xinput is supported, DirectInput is not and there is a lot of
> controllers out there that are not Xinput.
> Trying to save a file locally is a pain, you have to simulate a download.
> Loading a audio file manipulating it and saving it again is not the same as
> with a native app, instead you end up with a duplicate file in the download
> folder instead of the original files folder.
>
> If there is a requirement for Oracle 12G on a mobile phone and then I’m
> sure they will build it. In the meantime the fundamental
> service/retail-delivery shift that the world is currently experiencing is
> crying out for background geolocation Uber, Dominos, GrindR, Facebook,
> Deliveroo, Maps/Navigation and on and on.
>
> Please let WebApps compete with Native Apps!
>
> There is a difference between a Webapp that supports offline and a offline
> "HTML5" app.
>
> Using NWN.js and Electron turns it into a native app anyway, ideally one
> should not have to do this, at least not for "simple" apps.
> PS. The cognoscente are once more assembling on April 4-5 for a Japanese
> junket on ServiceWorkers to yet again wax bollocks on "offline first" :-(
>
> What is wrong with offline first? If you have a Ohms law calculator and
> your internet is down there is no reason why it should not still work if it
> was saved in the cache or even locally as a .html file and opened in the
> browser while the internet is down.
>
> If ifs and ands were pots and pans there’d be no worker for new age
> travelers.
>
> It's rare for the internet to be down for long periods of time, but
> usually it goes down wen it's the least convenient and not having apps
> break and still work is important in those cases.
>
> I don’t believe network reliability is an issue for the vast majority of
> the money-spending public.
>
> Please lobby 

Re: [whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF Success Prevention Depts out of the water!

[Richard Maher]

Hopefully the quoting below is legible: -

-Original Message-
From: Richard's Hotmail [mailto:maher...@hotmail.com] 
Sent: Wednesday, April 19, 2017 7:09 AM
To: 'whatwg@lists.whatwg.org'
Subject: Re: [whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF
Success Prevention Depts out of the water!

> On Tue, Mar 28, 2017 at 9:30 AM, Roger
Hågensen <rh_wha...@skuldwyrm.no> wrote:
>> On 2017-03-27 05:50, Richard Maher wrote:
>> Broadcast Messaging and Topic Based subscription is now available to your
>> WebApp just like native Apps thanks to FCM.
>>
>> https://firebase.google.com/docs/cloud-messaging/js/send-multiple
>>
>> I am absolutely ecstatic about this, as we all should be, and equally
>> grateful to FCM for having managed to bypass the recalcitrance and sheer
>> bloody-mindedness of spec-authors to provide functionality that everyone
>> outside the ivory-towers was begging for.
>>
>> I thought WhatWG was set up to challenge the delusional elite a la mode
de
>> HTML5? Why the silence?
> 
> Maybe because this is a Google API and cloud service rather than a 
> web standard added to Chrome, Firefox, Edge, Safari, 
> Opera, Vivaldi etc? Unless I'm missing some important detail here!

Yes it is a Google API. A browser agnostic Google API that runs on Chrome,
Firefox, Samsung, soon to be Opera, and Edge. Anything that runs
ServiceWorker and Push. While I would’ve preferred W3C/IETF to see the sense
and requirement for Topic-based subscriptions and broadcast messaging, the
Firebase API is from the same stable as other ubiquitous APIs such as Google
Maps? Analytics? Google+ logon.

>> Anyway rejoice and be glad as Native Apps have one less stick to beat us
>> over the head with. And you Firefox fans are no longer stuck with
Mozilla's
>> third-rate AutoPush!
>
> I'm not aware of anything called autopush, is this another cloud API?
> Or do you mean https://developer.mozilla.org/en/docs/Web/API/Push_API ?

See:  - https://mozilla-push-service.readthedocs.io/en/latest/
 

>> Now if we can only get background geolocation with ServiceWorkers nothing
>> can stop WebApps: -
>> https://github.com/w3c/ServiceWorker/issues/745

> Considering I'm coding both native and "HTML5" based "apps" 
> there is far more that needs to be improved.
> There is no way to reliably know how much LocalStorage or 
> IndexDB space the web app has, trying to access or list files 
> locally in a folder is not possible, something as simple as a 
> editable soundboard can't be made if it's run locally (via file:
protocol).
> While Xinput is supported, DirectInput is not and there is a lot of 
> controllers out there that are not Xinput.
> Trying to save a file locally is a pain, you have to simulate a download. 
> Loading a audio file manipulating it and saving it again is not the 
> same as with a native app, instead you end up with a duplicate file 
> in the download folder instead of the original files folder.

If there is a requirement for Oracle 12G on a mobile phone then I’m sure
they will build it. In the meantime the fundamental service/retail-delivery
shift that the world is currently experiencing is crying out for background
geolocation Uber, Dominos, GrindR, Facebook, Deliveroo, Maps/Navigation and
on and on. 

Please let WebApps compete with Native Apps! 

> There is a difference between a Webapp that supports offline 
> and a offline "HTML5" app.
>
> Using NWN.js and Electron turns it into a native app anyway, 
> ideally one should not have to do this, at least not for "simple" apps.
>> PS. The cognoscente are once more assembling on April 4-5 for a Japanese
>> junket on ServiceWorkers to yet again wax bollocks on "offline first" :-(
>
> What is wrong with offline first? If you have a Ohms law 
> calculator and your internet is down there is no reason why it 
> should not still work if it was saved in the cache or even locally 
> as a .html file and opened in the browser while the internet is down.

If ifs and ands were pots and pans there’d be no worker for new age
travelers.
 
> It's rare for the internet to be down for long periods of time, 
> but usually it goes down wen it's the least convenient and not 
> having apps break and still work is important in those cases.

I don’t believe network reliability is an issue for the vast majority of the
money-spending public.

>> Please lobby the names that can be found in the hall of shame here: -
>> https://github.com/w3c/ServiceWorker/issues/1053

> Hall of shame? It sounds like you have some form of personal agenda here.

My agenda is to get Background Geolocation out there on Web Apps before it
is too late. Service Worker extensibility seems ideal to me but I don't
really care how it is done as long as it gets done.

Cheers Richard

Re: [whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF Success Prevention Depts out of the water!

[Richard Maher]

On Tue, Mar 28, 2017 at 9:30 AM, Roger Hågensen 
> wrote:

On 2017-03-27 05:50, Richard Maher wrote:
Broadcast Messaging and Topic Based subscription is now available to your
WebApp just like native Apps thanks to FCM.

https://firebase.google.com/docs/cloud-messaging/js/send-multiple

I am absolutely ecstatic about this, as we all should be, and equally
grateful to FCM for having managed to bypass the recalcitrance and sheer
bloody-mindedness of spec-authors to provide functionality that everyone
outside the ivory-towers was begging for.

I thought WhatWG was set up to challenge the delusional elite a la mode de
HTML5? Why the silence?

Maybe because this is a Google API and cloud service rather than a web standard 
added to Chrome, Firefox, Edge, Safari, Opera, Vivaldi etc? Unless I'm missing 
some important detail here!

Yes it is a Google API. A browser agnostic Google API that runs on Chrome, 
Firefox, Samsung, soon to be Opera, and Edge. Anything that runs ServiceWorker 
and Push. While I would’ve preferred W3C/IETF to see the sense and requirement 
for Topic-based subscriptions and broadcast messaging, the Firebase API is from 
the same stable as other ubiquitous APIs such as Google Maps? Analytics? 
Google+ logon.

Anyway rejoice and be glad as Native Apps have one less stick to beat us
over the head with. And you Firefox fans are no longer stuck with Mozilla's
third-rate AutoPush!

I'm not aware of anything called autopush, is this another cloud API?
Or do you mean https://developer.mozilla.org/en/docs/Web/API/Push_API ?

See:  - https://mozilla-push-service.readthedocs.io/en/latest/


Now if we can only get background geolocation with ServiceWorkers nothing
can stop WebApps: -
https://github.com/w3c/ServiceWorker/issues/745

Considering I'm coding both native and "HTML5" based "apps" there is far more 
that needs to be improved.
There is no way to reliably know how much LocalStorage or IndexDB space the web 
app has, trying to access or list files locally in a folder is not possible, 
something as simple as a editable soundboard can't be made if it's run locally 
(via file: protocol).
While Xinput is supported, DirectInput is not and there is a lot of controllers 
out there that are not Xinput.
Trying to save a file locally is a pain, you have to simulate a download. 
Loading a audio file manipulating it and saving it again is not the same as 
with a native app, instead you end up with a duplicate file in the download 
folder instead of the original files folder.

If there is a requirement for Oracle 12G on a mobile phone and then I’m sure 
they will build it. In the meantime the fundamental service/retail-delivery 
shift that the world is currently experiencing is crying out for background 
geolocation Uber, Dominos, GrindR, Facebook, Deliveroo, Maps/Navigation and on 
and on.

Please let WebApps compete with Native Apps!

There is a difference between a Webapp that supports offline and a offline 
"HTML5" app.

Using NWN.js and Electron turns it into a native app anyway, ideally one should 
not have to do this, at least not for "simple" apps.
PS. The cognoscente are once more assembling on April 4-5 for a Japanese
junket on ServiceWorkers to yet again wax bollocks on "offline first" :-(

What is wrong with offline first? If you have a Ohms law calculator and your 
internet is down there is no reason why it should not still work if it was 
saved in the cache or even locally as a .html file and opened in the browser 
while the internet is down.

If ifs and ands were pots and pans there’d be no worker for new age travelers.

It's rare for the internet to be down for long periods of time, but usually it 
goes down wen it's the least convenient and not having apps break and still 
work is important in those cases.

I don’t believe network reliability is an issue for the vast majority of the 
money-spending public.

Please lobby the names that can be found in the hall of shame here: -
https://github.com/w3c/ServiceWorker/issues/1053

Hall of shame? It sounds like you have some form of personal agenda here.

My agenda is to get Background Geolocation out there on Web Apps before it is 
too late. Service Worker extensibility seems ideal to me but I don't really 
care how it is done as long as it gets done.

Cheers Richard

Re: [whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF Success Prevention Depts out of the water!

[Roger Hågensen]

On 2017-03-27 05:50, Richard Maher wrote:

Broadcast Messaging and Topic Based subscription is now available to your
WebApp just like native Apps thanks to FCM.

https://firebase.google.com/docs/cloud-messaging/js/send-multiple

I am absolutely ecstatic about this, as we all should be, and equally
grateful to FCM for having managed to bypass the recalcitrance and sheer
bloody-mindedness of spec-authors to provide functionality that everyone
outside the ivory-towers was begging for.

I thought WhatWG was set up to challenge the delusional elite a la mode de
HTML5? Why the silence?


Maybe because this is a Google API and cloud service rather than a web 
standard added to Chrome, Firefox, Edge, Safari, Opera, Vivaldi etc? 
Unless I'm missing some important detail here!



Anyway rejoice and be glad as Native Apps have one less stick to beat us
over the head with. And you Firefox fans are no longer stuck with Mozilla's
third-rate AutoPush!


I'm not aware of anything called autopush, is this another cloud API?
Or do you mean https://developer.mozilla.org/en/docs/Web/API/Push_API ?


Now if we can only get background geolocation with ServiceWorkers nothing
can stop WebApps: -
https://github.com/w3c/ServiceWorker/issues/745


Considering I'm coding both native and "HTML5" based "apps" there is far 
more that needs to be improved.
There is no way to reliably know how much LocalStorage or IndexDB space 
the web app has, trying to access or list files locally in a folder is 
not possible, something as simple as a editable soundboard can't be made 
if it's run locally (via file: protocol).
While Xinput is supported, DirectInput is not and there is a lot of 
controllers out there that are not Xinput.
Trying to save a file locally is a pain, you have to simulate a 
download. Loading a audio file manipulating it and saving it again is 
not the same as with a native app, instead you end up with a duplicate 
file in the download folder instead of the original files folder.


There is a difference between a Webapp that supports offline and a 
offline "HTML5" app.


Using NWN.js and Electron turns it into a native app anyway, ideally one 
should not have to do this, at least not for "simple" apps.



PS. The cognoscente are once more assembling on April 4-5 for a Japanese
junket on ServiceWorkers to yet again wax bollocks on "offline first" :-(


What is wrong with offline first? If you have a Ohms law calculator and 
your internet is down there is no reason why it should not still work if 
it was saved in the cache or even locally as a .html file and opened in 
the browser while the internet is down. It's rare for the internet to be 
down for long periods of time, but usually it goes down wen it's the 
least convenient and not having apps break and still work is important 
in those cases.



Please lobby the names that can be found in the hall of shame here: -
https://github.com/w3c/ServiceWorker/issues/1053


Hall of shame? It sounds like you have some form of personal agenda here.


--
Roger Hågensen,
Freelancer, Norway.