4 ms·

The push API is pretty awesome, the key difference between it and websockets in term of what it offers is this bit: > A push service allows a webapp server to

The push API is pretty awesome, the key difference between it and websockets in term of what it offers is this bit: > A push service allows a webapp server to send messages to a webapp, regardless of whether the webapp is currently active on the user agent So you can send push notifications to a user even if they don't have a tab open to your website.

pan69 12y ago
Is that the bit (step 1) where they install the Service Worker? I.e. regardless of whether or not the page is open, the Service Worker is active?
- m_eiman 12y ago
  Yes, and it has to maintain TCP connections with every push source you've registered, including re-connecting whenever your network situation changes. IMHO, this will lead to a lot of wasted bandwidth. Might not be a problem on desktop machines, but on mobile devices…
  - zachlatta 12y ago
    It already happens on mobile devices through APNs, GCM, and the like. Maybe mobile web browsers will have backing cloud services that use the mobile OS's recommended push server as a frontend to the mobile device? That doesn't sound like an ideal scenario though, considering that then the cloud service would have an enormous amount of user data going through it.
    - lucian1900 12y ago
      APN and GCM multiplex messages from all apps on a single TCP connection. That makes a significant difference.
      - domenicd 12y ago
        That is how the Push API works as well. In fact usually developers will be using APN or GCM when they use the Push API.
  - aikah 12y ago
    well how do smartphones and apps deal with push notification in general? (i mean native apps)
    - nostrademons 12y ago
      The OS provides a messaging service. Applications can request differing levels of latency guarantee. The default on Android is to deliver immediately unless the device is off or sleeping, in which case it'll be queued for up to 4 weeks or until the device wakes up, whichever comes first. There is also throttling functionality, where an app that sends too many messages in a short period of time will find that its messages are only delivered when the device radio has to wake up for other non-throttled messages.
    - m_eiman 12y ago
      With iOS, Apple provides a service that event sources push their messages to, and a single TCP connection is maintained with the device regardless of the number of event sources. Google has something similar, if not identical.
SynchrotronZ 12y ago
I'm... not sure I want this. It sounds pretty useful/fun form a programmers perspective. But from an end-user perspective I fear that it will lead too various "features" hogging resources. I would assume I could block them client-side, but I'm also the family-tech and quite frankly I don't expect my grandparents to do the same.
- mmahemoff 12y ago
  "User agents must not provide Push API access to webapps without the express permission of the use" I share your concern. but I share a great fear that web apps will become increasingly irrelevant if they remain just documents that can't do anything when they're not explicitly in a running tab/window. The permission requirement is the same one that allows for local storage, which could have caused great problems, but has so far held up well.
  - travisby 12y ago
    And the Ask toolbar doesn't get installed without expressed permission, either.
  - dspillett 12y ago
    > The permission requirement is the same one that allows for local storage Assuming this does not allow the push of UI interaction, then yes. If it would allow UI responses to be pushed then we would be one XSS vulnerability or "uneducated users" away from a new set of exploits for forcing pop-under advertising , and other potentially more insidious problems, through. Local Storage and Index DB are storage only so the only attack routes are DoS-due-to-disk-full-errors which is generally less attractive (you can make more money pushing stuff to people than pushing people off the network).
- vbezhenar 12y ago
  Safari supports push notifications from websites for a while. I've found it convenient for the news websites I often visit just to check for new content. It's like RSS integrated into OS. One can misuse it, but generally it's useful.
smanuel 12y ago
> The push API is pretty awesome The idea behind this is awesome (although we already have this for some platforms - e.g. https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html https://developer.apple.com/library/mac/documentation/Networ...) But the API looks over-engineered. e.g. navigator.serviceWorker.ready.then(function(serviceWorkerRegistration) { serviceWorkerRegistration.pushRegistrationManager.register().then(...
- rakoo 12y ago
  I believe this spec is aiming to standardize the service offered primarily by Google (GCM) and Apple (APN), and open/standardize it for other people like pubnub/parse/pusher/...
- mmastrac 12y ago
  The new web APIs are promise-ified by default rather than using the callback model of the past. So rather than register(callback), it's register().then(...). Whether this is a good thing or not is another question I don't know the answer to.
  - smanuel 12y ago
    My comment was mainly about serviceWorker.ready.then. I've never seen a JS API using such pattern - the name of the event as a property which is a promise. A manager object/class also usually rings a bell. Not that I'm an API specialist but I would rather implement it as: document.addEventListener("serviceready", function() { window.pushNotification.register().then(.....
    - AgentME 12y ago
      For an event that only happens once, then the navigator.serviceWorker.ready.then(function(){... version is preferable to document.addEventListener("serviceready", function() { because A) you don't have to worry about removing your event listener after the fact, and B) if the event has already happened, then your callback will be called immediately.
andrewstuart2 12y ago
>The push API is pretty awesome, the key difference between it and websockets in term of what it offers is this bit: > > A push service allows a webapp server to send messages to a webapp, regardless of whether the webapp is currently active on the user agent. Actually, the difference you describe is what Server-Sent Events [1] already provide: one-way notifications vs bidirectional communication with websockets. This spec, rather, would standardize an API for a single-connection (read: better battery life) push server that third party webapps can use in the same way Google Cloud Messenger is used by third-party application servers for android apps. [1] http://www.w3.org/TR/eventsource/ http://www.w3.org/TR/eventsource/

pan69 12y ago

Is that the bit (step 1) where they install the Service Worker? I.e. regardless of whether or not the page is open, the Service Worker is active?

m_eiman 12y ago
Yes, and it has to maintain TCP connections with every push source you've registered, including re-connecting whenever your network situation changes. IMHO, this will lead to a lot of wasted bandwidth. Might not be a problem on desktop machines, but on mobile devices…
- zachlatta 12y ago
  It already happens on mobile devices through APNs, GCM, and the like. Maybe mobile web browsers will have backing cloud services that use the mobile OS's recommended push server as a frontend to the mobile device? That doesn't sound like an ideal scenario though, considering that then the cloud service would have an enormous amount of user data going through it.
  - lucian1900 12y ago
    APN and GCM multiplex messages from all apps on a single TCP connection. That makes a significant difference.
    - domenicd 12y ago
      That is how the Push API works as well. In fact usually developers will be using APN or GCM when they use the Push API.
- aikah 12y ago
  well how do smartphones and apps deal with push notification in general? (i mean native apps)
  - nostrademons 12y ago
    The OS provides a messaging service. Applications can request differing levels of latency guarantee. The default on Android is to deliver immediately unless the device is off or sleeping, in which case it'll be queued for up to 4 weeks or until the device wakes up, whichever comes first. There is also throttling functionality, where an app that sends too many messages in a short period of time will find that its messages are only delivered when the device radio has to wake up for other non-throttled messages.
  - m_eiman 12y ago
    With iOS, Apple provides a service that event sources push their messages to, and a single TCP connection is maintained with the device regardless of the number of event sources. Google has something similar, if not identical.

SynchrotronZ 12y ago

I'm... not sure I want this. It sounds pretty useful/fun form a programmers perspective. But from an end-user perspective I fear that it will lead too various "features" hogging resources. I would assume I could block them client-side, but I'm also the family-tech and quite frankly I don't expect my grandparents to do the same.

mmahemoff 12y ago
"User agents must not provide Push API access to webapps without the express permission of the use" I share your concern. but I share a great fear that web apps will become increasingly irrelevant if they remain just documents that can't do anything when they're not explicitly in a running tab/window. The permission requirement is the same one that allows for local storage, which could have caused great problems, but has so far held up well.
- travisby 12y ago
  And the Ask toolbar doesn't get installed without expressed permission, either.
- dspillett 12y ago
  > The permission requirement is the same one that allows for local storage Assuming this does not allow the push of UI interaction, then yes. If it would allow UI responses to be pushed then we would be one XSS vulnerability or "uneducated users" away from a new set of exploits for forcing pop-under advertising , and other potentially more insidious problems, through. Local Storage and Index DB are storage only so the only attack routes are DoS-due-to-disk-full-errors which is generally less attractive (you can make more money pushing stuff to people than pushing people off the network).
vbezhenar 12y ago
Safari supports push notifications from websites for a while. I've found it convenient for the news websites I often visit just to check for new content. It's like RSS integrated into OS. One can misuse it, but generally it's useful.

smanuel 12y ago

> The push API is pretty awesome The idea behind this is awesome (although we already have this for some platforms - e.g. https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html https://developer.apple.com/library/mac/documentation/Networ...) But the API looks over-engineered. e.g. navigator.serviceWorker.ready.then(function(serviceWorkerRegistration) { serviceWorkerRegistration.pushRegistrationManager.register().then(...

rakoo 12y ago
I believe this spec is aiming to standardize the service offered primarily by Google (GCM) and Apple (APN), and open/standardize it for other people like pubnub/parse/pusher/...
mmastrac 12y ago
The new web APIs are promise-ified by default rather than using the callback model of the past. So rather than register(callback), it's register().then(...). Whether this is a good thing or not is another question I don't know the answer to.
- smanuel 12y ago
  My comment was mainly about serviceWorker.ready.then. I've never seen a JS API using such pattern - the name of the event as a property which is a promise. A manager object/class also usually rings a bell. Not that I'm an API specialist but I would rather implement it as: document.addEventListener("serviceready", function() { window.pushNotification.register().then(.....
  - AgentME 12y ago
    For an event that only happens once, then the navigator.serviceWorker.ready.then(function(){... version is preferable to document.addEventListener("serviceready", function() { because A) you don't have to worry about removing your event listener after the fact, and B) if the event has already happened, then your callback will be called immediately.

andrewstuart2 12y ago

>The push API is pretty awesome, the key difference between it and websockets in term of what it offers is this bit: > > A push service allows a webapp server to send messages to a webapp, regardless of whether the webapp is currently active on the user agent. Actually, the difference you describe is what Server-Sent Events [1] already provide: one-way notifications vs bidirectional communication with websockets. This spec, rather, would standardize an API for a single-connection (read: better battery life) push server that third party webapps can use in the same way Google Cloud Messenger is used by third-party application servers for android apps. [1] http://www.w3.org/TR/eventsource/ http://www.w3.org/TR/eventsource/