- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 16 Oct 2014 10:51:41 -0700
- To: Shijun Sun <shijuns@microsoft.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Domenic Denicola <domenic@domenicdenicola.com>, Nikhil Marathe <nsm.nikhil@gmail.com>, Jonas Sicking <jonas@sicking.cc>, John Mellor <johnme@google.com>, public-webapps <public-webapps@w3.org>
On 16 October 2014 08:55, Shijun Sun <shijuns@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.
Received on Thursday, 16 October 2014 17:52:09 UTC