Re: Push API and Service Workers

On 16 October 2014 16:22, Shijun Sun <shijuns@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
>