Re: Push API and Service Workers
On 10/22/14 1:21 AM, Shijun Sun wrote: On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote: If we want to take advantage of this opportunity, perhaps you should first flesh out specific issue(s) to discuss, and then try to agree on a time + day slot in advance of the meeting. Thanks Arthur for the suggestion. I think we can take a half hour timeslot to discuss the E2E flow for the RTC scenarios using push messages. The goal is to make sure we understand the steps and options in the whole E2E story. If this is a right topic and there is enough interest in the group, I can set up a Doodle to help us pick the timeslot. Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27: https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27 If people want to attend remotely, see: https://www.w3.org/wiki/Webapps/November2014Meeting#Meeting_Logistics -Thanks, AB
RE: Push API and Service Workers
On October 24, 2014 4:30 AM, Arthur Barstow wrote: On 10/22/14 1:21 AM, Shijun Sun wrote: I think we can take a half hour timeslot to discuss the E2E flow for the RTC scenarios using push messages. The goal is to make sure we understand the steps and options in the whole E2E story. Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27: Thanks Arthur! Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be more productive for folks having hands-on experience with Service Workers to participate. Best, Shijun [1] https://github.com/w3c/push-api/issues/84 [2] https://github.com/w3c/push-api/issues/85
Re: Push API and Service Workers
On 10/24/14 11:36 AM, Shijun Sun wrote: On October 24, 2014 4:30 AM, Arthur Barstow wrote: On 10/22/14 1:21 AM, Shijun Sun wrote: I think we can take a half hour timeslot to discuss the E2E flow for the RTC scenarios using push messages. The goal is to make sure we understand the steps and options in the whole E2E story. Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27: Thanks Arthur! Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be more productive for folks having hands-on experience with Service Workers to participate. Good point. Since Jungkee is attending the meeting (and I'll chase after Alex to see if he can join), I created a 13:00-14:00 Push API and Service Workers block on Monday and added links to the 2 issues below. https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27 -Art Best, Shijun [1] https://github.com/w3c/push-api/issues/84 [2] https://github.com/w3c/push-api/issues/85
Re: Push API and Service Workers
On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote: * Push doesn't actually need SW's ability to intercept network communications on behalf of a web page. * You can imagine a push-handling SW that does all sorts of complicated processing of notifications, downloading things to a local database, but does not cache/intercept a web page. * This ties into the discussion of whether it should be possible to register a SW without giving it a network-intercept namespace As was discussed over in https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60304515 earlier today, you need a scope for all uses of SW, because you need to *request permission* on a *page*, not within a SW (so the user has appropriate context on whether to grant the permission or not), and the scope maps the page to the SW that the registration is for. (The permission grant is actually per-origin, not per-scope/SW, but the registration itself is per-scope/SW, and it has to be done from within a page context because there *might* be a permission grant needed.) ~TJ
Re: Push API and Service Workers
On Thu, Oct 23, 2014 at 2:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote: * Push doesn't actually need SW's ability to intercept network communications on behalf of a web page. * You can imagine a push-handling SW that does all sorts of complicated processing of notifications, downloading things to a local database, but does not cache/intercept a web page. * This ties into the discussion of whether it should be possible to register a SW without giving it a network-intercept namespace As was discussed over in https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60304515 earlier today, you need a scope for all uses of SW, because you need to *request permission* on a *page*, not within a SW (so the user has appropriate context on whether to grant the permission or not), and the scope maps the page to the SW that the registration is for. (The permission grant is actually per-origin, not per-scope/SW, but the registration itself is per-scope/SW, and it has to be done from within a page context because there *might* be a permission grant needed.) Yes, you need to ask for permission within a page. But that page doesn't have to have any particular relation to the scope of the SW that it's asking for. It just needs to be same-origin with that SW. As the API is structured, any page on a website can grab any SW registration, and call registerPush or registerGeoFence on that SW registration. So I don't see how the scope of the SW matters. / Jonas
RE: Push API and Service Workers
On 21 Oct 2014 16:53, Shijun Sun shij...@microsoft.com wrote: On Monday, October 20, 2014 9:42 AM, Jake Archibald wrote: Things I guess you'd do as a result of a push message: One of the most typical scenarios is * show a toast notification (e.g. for a new email) * user chooses to dismiss the notification, so not to read the email right away That is it. From the power efficiency perspective, the browser itself doesn't have to always wake up to process the push message. It should be a decision by web developers whether the message should be handled explicitly by the service worker every time it arrives. To reiterate from my previous message: Updating caches should be common, and it's something most native apps get very wrong. Take Twitter for example, I can tap a notification that shows a partial tweet, but I have poor/no connectivity so the full tweet doesn't load. The notification is now gone, so I'm left with less information than I had before I tapped the notification. Twitter should download and cache the full tweet before showing the notification. Taking the email example specifically, the gmail app does the right thing. Not only do you get a notification, but the email is also cached for offline viewing so tapping the notification works regardless of connectivity at moment of tapping. This is exactly the wrong time to guess what high-level things developers want to do and build APIs to do those imagined things.
Re: Push API and Service Workers
On 10/16/14 5:52 PM, Shijun Sun wrote: On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in waking an idle device and that turns into a very long post-dial delay. People abandon calls for that sort of delay. Not saying that you are doing it wrong or anything, but just trying to set the right expectations. The RTC scenario is listed explicitly as one of the use cases in the Push API wiki [1]. I expect there is enough interest in the group. Should we allocate some cycles in TPAC to figure out details of the E2E flow? Re scheduling time at TPAC with non group members and remote participants ... We can accommodate remote participants via the W3C phone conference bridge and we will use the W3C's #webapps IRC channel (see [1]). If we want to take advantage of this opportunity, perhaps you should first flesh out specific issue(s) to discuss, and then try to agree on a time + day slot in advance of the meeting. (Currently, there are quite a few open slots on Oct 27 and 28 [2].) -AB [1] https://www.w3.org/wiki/Webapps/November2014Meeting#Meeting_Logistics [2] https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27
RE: Push API and Service Workers
On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote: If we want to take advantage of this opportunity, perhaps you should first flesh out specific issue(s) to discuss, and then try to agree on a time + day slot in advance of the meeting. Thanks Arthur for the suggestion. I think we can take a half hour timeslot to discuss the E2E flow for the RTC scenarios using push messages. The goal is to make sure we understand the steps and options in the whole E2E story. If this is a right topic and there is enough interest in the group, I can set up a Doodle to help us pick the timeslot.
Re: Push API and Service Workers
On 19 October 2014 19:18, Shijun Sun shij...@microsoft.com wrote: It'd be great if the Push API spec allows the web developers to have flexibility to leverage the generic actions, or rely on a service worker, or maybe doing both. I imagine that we will permit the use of whatever a service worker has access to. Some of that is going to require prior arrangement (i.e., consent prompts might be required to enable a full screen alert, though maybe toasts).
RE: Push API and Service Workers
On Monday, October 20, 2014 5:41 AM, Martin Thomson wrote: I imagine that we will permit the use of whatever a service worker has access to. Some of that is going to require prior arrangement (i.e., consent prompts might be required to enable a full screen alert, though maybe toasts). Fully agree that we should follow the same user consent requirement. BTW, I have opened a spec bug to track the topic (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27108). Thanks, Shijun
Re: Push API and Service Workers
On 20 October 2014 03:18, Shijun Sun shij...@microsoft.com wrote: What I'd like to get across is when the push client can handle generic actions already, such as posting a toast notifications, waking up the browser (or a subset of it) and let service workers to display each notification might not be the best practice from performance perspective, Things I guess you'd do as a result of a push message: * Update caches * Show a notification * Focus a tab tell it to do something Updating caches should be common, and it's something most native apps get very wrong. Take Twitter for example, I can tap a notification that shows a partial tweet, but I have poor/no connectivity so the full tweet doesn't load. The notification is now gone, so I'm left with less information than I had before I tapped the notification. Twitter should download and cache the full tweet before showing the notification. On top of that, there are conditions that could mean I don't want to show a notification, or hide an existing one: * User already has relevant content focused visible * User reads the content elsewhere (a push message would trigger the hiding of the current notification) Also, if the user dismisses the notification, I may wish to send that info back to the server, and push a message that hides the notification on other devices. When you multiply that all together, we've got a large API, and we've probably done the appcache thing and forgotten about particular use-cases. In terms of RTC, let's imagine we receive a Jeff's calling push message. At this point I'd want to: * If there isn't a tab open to the calling app, open one * Else use the existing one * Focus it (forcing it over any lock screen - we don't have a way to do this yet) * postMessage the page telling it who's calling * If a call is already in progress, show a small overlay indicating the new call, with handling options * Else show a full screen Jeff's calling message with handling options, play ringtone until handled If the call is answered on a particular device, you'll want to push to other devices to stop ringing. That's a rough design for what I think should happen, other people may have better ideas. I don't think now's the time to give a particular design a high-level API. I'd rather follow the extensible web model and expose the primitives, then build higher level bits based on common patterns that are observed.
Re: Push API and Service Workers
On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@microsoft.com wrote: My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. Yes, this is how the spec is defined. The spec leaves it up to the implementation how to transport the information from the push server to the device. This part is entirely transparent to the webapp, even once we specify the server side of the push feature, and so is up to the implementation to do through whatever means it wants. / Jonas
RE: Push API and Service Workers
On Sunday, October 19, 2014 6:43 PM, Jonas Sicking wrote: On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@microsoft.com wrote: My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. Yes, this is how the spec is defined. The spec leaves it up to the implementation how to transport the information from the push server to the device. This part is entirely transparent to the webapp, even once we specify the server side of the push feature, and so is up to the implementation to do through whatever means it wants. Yes, I understand the spec is independent from how push server communicates to the device. What I'd like to get across is when the push client can handle generic actions already, such as posting a toast notifications, waking up the browser (or a subset of it) and let service workers to display each notification might not be the best practice from performance perspective, especially when the user does not want to pick up each incoming video call or read each incoming emails right away. It'd be great if the Push API spec allows the web developers to have flexibility to leverage the generic actions, or rely on a service worker, or maybe doing both. To folks who are interested, here is a link [1] to how the push client and push server operate on current Windows devices. As we indicated there, power-efficient is quite important to the scenarios. [1] http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx Thanks, Shijun
Re: Push API and Service Workers
On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@microsoft.com wrote: My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. You are correct about leveraging the underlying platform's push system, but without a serviceworker you still require the webapp itself to have an open window to handle the request, otherwise you risk launching an app with a UI when the user is not expecting it. Now the same thing can be accomplished by a push specific system where the app author declares a tiny JS file to be used as the push handler. In this case the 'tiny JS file' is the serviceworker since we are already building the infrastructure in. Nikhil
Re: Push API and Service Workers
On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@microsoft.com wrote: This is very helpful. I assume the browser running the service worker can be a very light-weight version (or a subset of the full browser) since we don't need to render an actual webpage. Is that the right expectation? If you can split that somehow it might be somewhat lighter weight, yes, but I wouldn't expect that to be easy. I agree we don't want to display a notification for each push message. Meanwhile, for certain type of messages (e.g. realtime communications), we don't want to miss them or delay them, e.g. an incoming video call. I'm trying to figure out which of the following should be the right flow for the scenario. Please let me know if you see other options. I started an exploratory thread on letting the service worker open up some kind of window that could help with this, but I suspect it's still too early. (1) the Push Client displays a notification right away, the user chooses to pick up the call or dismiss, the browser launch with the app based on user decision. (2) The Push Client wakes up the browser, which start the service worker, which pushes a notification, then the user can decide whether to answer the call, the app launches based on user decision or browser goes back to sleep. Re #2, I'm still fuzzy about the schedule of the service worker, so ask the question again, would there be a delay if the service worker is not scheduled to run when the message comes in? (1) will also likely involve a service worker or an even slower network fetch to get to the application, as I pointed out. -- https://annevankesteren.nl/
RE: Push API and Service Workers
On Thursday, October 16, 2014 8:29 AM, Anne van Kesteren wrote On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@microsoft.com wrote: (1) the Push Client displays a notification right away, the user chooses to pick up the call or dismiss, the browser launch with the app based on user decision. (2) The Push Client wakes up the browser, which start the service worker, which pushes a notification, then the user can decide whether to answer the call, the app launches based on user decision or browser goes back to sleep. Re #2, I'm still fuzzy about the schedule of the service worker, so ask the question again, would there be a delay if the service worker is not scheduled to run when the message comes in? (1) will also likely involve a service worker or an even slower network fetch to get to the application, as I pointed out. Re#1, most devices have native push client already which can connect to its notification servers in the cloud. I expect simple/generic actions can be defined without involving any script engine (or service worker). RE the slower network fetch, it might not be the best user experience on mobile devices if we open up websockets and prefetch the app page before the user consent (i.e. to pick up the call). Of course, it can be a developer decision if the spec (and web platforms) provide the options. Re #2, it'd be great if some folks could comment on the scheduling and latency question. Thanks, Shijun
Re: Push API and Service Workers
On 16 October 2014 08:55, Shijun Sun shij...@microsoft.com wrote: Re #2, it'd be great if some folks could comment on the scheduling and latency question. There are number of variations on how this all works out. And multiple sources of latency. A mobile device in a low power state follows a process that is approximately: 1. network pages the device 2. device establishes a network context (considerable delay in some cases here...I've heard 2s isn't unusual...gah!) 3. network delivers the push message 4. OS delivers to push service on device (some services may initiate a user notification at this point based on the message contents, but it isn't a default mode) 5. OS awakens a push handler (a subset of the application) 6. push handler runs code to determine what to do, which may be Steps 5 and 6 are entirely analogous to the service worker case. The problem that Anne highlighted is the risk that the service worker requires download and installation when the event arrives. I think that we should be recommending that push messages are run from a previously installed (and cached) service worker. Latency really matters here. We could, of course, get fancy and require update of the SW if it has expired from cache, or maybe allow update for messages that are marked low priority, but I'd consider that to be a second-order optimization.
Re: Push API and Service Workers
On 16 October 2014 16:22, Shijun Sun shij...@microsoft.com wrote: On Thursday, October 16, 2014 12:42 AM, Anne van Kesteren wrote: 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. This is very helpful. I assume the browser running the service worker can be a very light-weight version (or a subset of the full browser) since we don't need to render an actual webpage. Is that the right expectation? Yes, the subset required by Service Workers consists of things like a JavaScript engine, network stack, local storage, and an implementation of the APIs exposed to Service Workers. But you don't need a DOM tree, rendering/graphics, UI etc. So the battery cost and RAM usage can both be reduced somewhat, depending on how modular your browser architecture is. 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. I agree we don't want to display a notification for each push message. Meanwhile, for certain type of messages (e.g. realtime communications), we don't want to miss them or delay them, e.g. an incoming video call. I'm trying to figure out which of the following should be the right flow for the scenario. Please let me know if you see other options. (1) the Push Client displays a notification right away, the user chooses to pick up the call or dismiss, the browser launch with the app based on user decision. (2) The Push Client wakes up the browser, which start the service worker, which pushes a notification, then the user can decide whether to answer the call, the app launches based on user decision or browser goes back to sleep. Re #2, I'm still fuzzy about the schedule of the service worker, so ask the question again, would there be a delay if the service worker is not scheduled to run when the message comes in? I'm not sure what you mean by 'scheduled', but no. A key benefit of Service Workers is that the browser can start and stop them whenever it feels like. Thus Service Workers are usually stopped, and get woken up on demand to handle events like incoming push messages. In our prototype on Android, it takes less than a second (not yet optimized) to wake up Chrome from a cold start and handle the event in a Service Worker (the demo writes to IndexedDB and shows a notification), versus less than 100ms to handle the event when Chrome and the SW are already running. Since push messages aren't usually triggered by a user action (like a button click), but instead by some external event, these latencies are already likely to be imperceptible to users. (If you're interested in scheduling SWs to run periodically in the background, there's been a proposed Background Sync https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md API that might permit that; but that's independent from the Push API). Hope that helps, John Best, Shijun
Re: Push API and Service Workers
On 16 October 2014 11:17, John Mellor joh...@google.com wrote: In our prototype on Android, it takes less than a second (not yet optimized) to wake up Chrome from a cold start and handle the event in a Service Worker (the demo writes to IndexedDB and shows a notification), versus less than 100ms to handle the event when Chrome and the SW are already running. Since push messages aren't usually triggered by a user action (like a button click), but instead by some external event, these latencies are already likely to be imperceptible to users. If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in waking an idle device and that turns into a very long post-dial delay. People abandon calls for that sort of delay. Not saying that you are doing it wrong or anything, but just trying to set the right expectations.
RE: Push API and Service Workers
On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in waking an idle device and that turns into a very long post-dial delay. People abandon calls for that sort of delay. Not saying that you are doing it wrong or anything, but just trying to set the right expectations. The RTC scenario is listed explicitly as one of the use cases in the Push API wiki [1]. I expect there is enough interest in the group. Should we allocate some cycles in TPAC to figure out details of the E2E flow? [1] http://www.w3.org/2008/webapps/wiki/Push_API
Push API and Service Workers
Hi, I'm with the IE Platform team at Microsoft. I joined the WebApps WG very recently. I am looking into the Push API spec, and got some questions. Hope to get help from experts in the WG. The current API definition is based on an extension of the Service Workers. I'd like to understand whether the Service Workers is a must-have dependency for all scenarios. It seems some basic scenarios can be enabled without the Service Worker if the website can directly create a PushRegistrationManager. I'm looking at Fig. 1 in the spec. If the user agent can be the broker between the Push client and the webpage, it seems some generic actions can be defined without the Service Workers - for example immediately display a toast notification with the push message. It is very likely I have missed some basic design principle behind the current API design. It'd be great if someone could share insights on the scenarios and the normative dependency on the Service Workers. All the Best, Shijun
RE: Push API and Service Workers
I'm not an expert either, but it seems to me that push without service workers (or some other means of background processing) is basically just server-sent events. That is, you could send push notifications to an active webpage over a server-sent events channel (or web socket, or long-polling...), which would allow it to display a toast notification with the push message. So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities.
RE: Push API and Service Workers
My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Wednesday, October 15, 2014 2:59 PM To: Shijun Sun; public-webapps Subject: RE: Push API and Service Workers I'm not an expert either, but it seems to me that push without service workers (or some other means of background processing) is basically just server-sent events. That is, you could send push notifications to an active webpage over a server-sent events channel (or web socket, or long-polling...), which would allow it to display a toast notification with the push message. So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities.
Re: Push API and Service Workers
The hard question is: What do you do if there's an incoming push message for a given website, but the user doesn't have the website currently open. Service Workers provide the primitive needed to enable launching a website in the background to handle the incoming push message. Another solution would be to always open up a browser tab with the website in it. But that's only correct behavior for some types of push messages. I.e. some push messages should be handled without any UI being opened. Others should be opened by launching a attention window which is rendered even though the phone is locked. Others simply want to create a toast notification. We could add lots of different types of push messages. But that's a lot of extra complexity. And we'd have to add similar types of geofencing registrations, and types of alarm clock registrations, etc. 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. / Jonas On Wed, Oct 15, 2014 at 2:42 PM, Shijun Sun shij...@microsoft.com wrote: Hi, I'm with the IE Platform team at Microsoft. I joined the WebApps WG very recently. I am looking into the Push API spec, and got some questions. Hope to get help from experts in the WG. The current API definition is based on an extension of the Service Workers. I'd like to understand whether the Service Workers is a must-have dependency for all scenarios. It seems some basic scenarios can be enabled without the Service Worker if the website can directly create a PushRegistrationManager. I'm looking at Fig. 1 in the spec. If the user agent can be the broker between the Push client and the webpage, it seems some generic actions can be defined without the Service Workers - for example immediately display a toast notification with the push message. It is very likely I have missed some basic design principle behind the current API design. It'd be great if someone could share insights on the scenarios and the normative dependency on the Service Workers. All the Best, Shijun
Re: Push API and Service Workers
On 15 October 2014 23:07, Shijun Sun shij...@microsoft.com wrote: My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. The Push API doesn't use a direct connection between the app and the app server: instead it assumes that there is a direct connection between the UA and a push server of the UA's choice. Then the app server can send messages to the push server, which relays them to the UA, which delivers them to the Service Worker. 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 https://w3c.github.io/push-api/#widl-PushRegistration-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. --John
Re: Push API and Service Workers
On 15 October 2014 14:58, Domenic Denicola dome...@domenicdenicola.com wrote: So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities. That's not strictly true. 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.
RE: Push API and Service Workers
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
