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? >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? Best, Shijun
