Thanks folks for the quick responses to the questions! RE: [Martin Thomson] If I sit (as I do) with a tab open to gmail for a very long time, then it is of some advantage to me (and my network usage) to use something like push rather than websockets (or even server sent events). Besides, server sent events might be roughly equivalent, but they are horribly kludgy and suffer from robustness issues.
I think Martin made a very good point. For mobile devices, it is certainly undesirable to keep the websockets for a long time. RE: [Jonas Sicking] The current design separates the "trigger" from "what to do when the trigger fires". Which both makes for a smaller API, and for a more flexible design. That is a valid argument. To be clear, my question right now is not whether we need Service Workers in the spec. I'd like to understand how that works in typical scenarios and whether we need it in all scenarios. RE: [John Mellor] For example Android devices already maintain a persistent connection to Google Cloud Messaging (GCM) servers, so in our current prototype in Chrome for Android, we set GCM as the endpoint to which the app server sends messages, and GCM relays the messages to the Android device, which wakes up Chrome, which launches a Service Worker, and then app JS handles the message. 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. Anyway, my excuse to be new to the area ;-) Let's take the GCM example from another angle. 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. Is this a reasonable expectation for the E2E scenario? Would there be extra latency if we want to wait for the Service Worker to be ready (based on its schedule), which then pushes a web notification for user to take the call (or dismiss the call)? Best, Shijun
