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/
