Re: Push API and Service Workers

On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun <shijuns@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/

Received on Thursday, 16 October 2014 15:29:43 UTC