On Thu, Oct 16, 2014 at 3:58 AM, Shijun Sun <shij...@microsoft.com> wrote: > Besides, server sent events might be roughly equivalent, but they are > horribly kludgy and suffer from robustness issues.
You'll have to elaborate on this. Or perhaps file a bug against server-sent events explaining why so that can be pointed out in the specification. > My expectation would be the device (i.e. the push client) will pass the > message to the Service Worker (when it is active), and then the Service > Worker will wake up the browser. You need a browser to run a service worker. The browser is pinged and it might then decide to start running a service worker to process the incoming message, or maybe decide to hold onto it for a bit. If the browser is not running it might be booted, depends a bit on the implementation details. That will likely evolve over time. > Assuming we have a WebRTC app, which has registered for a push notification > at GCM. Now there is an incoming video call, while the browser is still > inactive. The notification from the web server will go to the GCM, which > relays it to the device push client, which displays a toast notification > *right away*, when user clicks, the browser is launched with the webapp to > take the call. Without service workers that application might not load fast enough over the network to take that call. Also, it seems undesirable to always get a notification for each incoming push message. It should just be a new communication channel for the application. -- https://annevankesteren.nl/
