- From: Shijun Sun <shijuns@microsoft.com>
- Date: Thu, 16 Oct 2014 15:55:23 +0000
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Martin Thomson <martin.thomson@gmail.com>, 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 Thursday, October 16, 2014 8:29 AM, Anne van Kesteren wrote >On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun <shijuns@microsoft.com> wrote: >> (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. Re#1, most devices have native push client already which can connect to its notification servers in the cloud. I expect simple/generic actions can be defined without involving any script engine (or service worker). RE the "slower network fetch", it might not be the best user experience on mobile devices if we open up websockets and prefetch the app page before the user consent (i.e. to pick up the call). Of course, it can be a developer decision if the spec (and web platforms) provide the options. Re #2, it'd be great if some folks could comment on the scheduling and latency question. Thanks, Shijun
Received on Thursday, 16 October 2014 15:55:57 UTC