Re: Push API and Service Workers

On Thu, Oct 16, 2014 at 3:58 AM, Shijun Sun <shijuns@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/

Received on Thursday, 16 October 2014 07:42:24 UTC