- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 16 Oct 2014 09:41:57 +0200
- To: Shijun Sun <shijuns@microsoft.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Domenic Denicola <domenic@domenicdenicola.com>, Nikhil Marathe <nsm.nikhil@gmail.com>, Jonas Sicking <jonas@sicking.cc>, John Mellor <johnme@google.com>, public-webapps <public-webapps@w3.org>
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