4 ms·

I hate to be pedantic but these are not push notifications. Those are the ones that can be sent even if the webapp is closed, for example, this Chrome demo: htt

by echeese 10y ago

I hate to be pedantic but these are not push notifications. Those are the ones that can be sent even if the webapp is closed, for example, this Chrome demo: https://developers.google.com/web/fundamentals/getting-started/push-notifications/?hl=en https://developers.google.com/web/fundamentals/getting-start...

andreasklinger 10y ago
unsure here but isnt it the same but in this case it is just not yet using a service worker to listen for new push notifications ?
jvehent 10y ago
See also https://hacks.mozilla.org/2016/01/web-push-arrives-in-firefox-44/ https://hacks.mozilla.org/2016/01/web-push-arrives-in-firefo... WebPush is (going to be) an IETF standard: https://datatracker.ietf.org/wg/webpush/documents/ https://datatracker.ietf.org/wg/webpush/documents/
- andrewstuart2 10y ago
  Yikes, that really seems like abuse of HTTP/2 semantics to me. My understanding has always been that server push in HTTP/2 is only intended to prime the client cache for requests you know they're about to (or likely to) make. [1] > Pushed responses are always associated with an explicit request from the client. I'd rather see additional frame types defined that allow for bidirectional communication (i.e. websockets 2.0) than overriding and conflating the PUSH_PROMISE frame type. [1] https://tools.ietf.org/html/rfc7540#section-8.2 https://tools.ietf.org/html/rfc7540#section-8.2
dang 10y ago
Ok we replaced 'push' with 'desktop' which is what the Github page says.
untog 10y ago
Sort of. There's nothing stopping you from using script inside a Service Worker to send those notifications. Calling them push notification is troublesome as the Web Push API and Notification API are actually two entirely separate things.
RealGeek 10y ago
I've built a plug & play app for Web Push Notifications. It comes with an analytics dashboard and an interface for users to manage their subscription. If anyone is interested to try it, you can see the demo at https://www.pushroll.com https://www.pushroll.com

by echeese 10y ago

andreasklinger 10y ago

unsure here but isnt it the same but in this case it is just not yet using a service worker to listen for new push notifications ?

jvehent 10y ago

See also https://hacks.mozilla.org/2016/01/web-push-arrives-in-firefox-44/ https://hacks.mozilla.org/2016/01/web-push-arrives-in-firefo... WebPush is (going to be) an IETF standard: https://datatracker.ietf.org/wg/webpush/documents/ https://datatracker.ietf.org/wg/webpush/documents/

andrewstuart2 10y ago
Yikes, that really seems like abuse of HTTP/2 semantics to me. My understanding has always been that server push in HTTP/2 is only intended to prime the client cache for requests you know they're about to (or likely to) make. [1] > Pushed responses are always associated with an explicit request from the client. I'd rather see additional frame types defined that allow for bidirectional communication (i.e. websockets 2.0) than overriding and conflating the PUSH_PROMISE frame type. [1] https://tools.ietf.org/html/rfc7540#section-8.2 https://tools.ietf.org/html/rfc7540#section-8.2

dang 10y ago

Ok we replaced 'push' with 'desktop' which is what the Github page says.

untog 10y ago

Sort of. There's nothing stopping you from using script inside a Service Worker to send those notifications. Calling them push notification is troublesome as the Web Push API and Notification API are actually two entirely separate things.

RealGeek 10y ago

I've built a plug & play app for Web Push Notifications. It comes with an analytics dashboard and an interface for users to manage their subscription. If anyone is interested to try it, you can see the demo at https://www.pushroll.com https://www.pushroll.com