- From: Shijun Sun <shijuns@microsoft.com>
- Date: Mon, 20 Oct 2014 02:18:06 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Domenic Denicola <domenic@domenicdenicola.com>, public-webapps <public-webapps@w3.org>
On Sunday, October 19, 2014 6:43 PM, Jonas Sicking wrote: >On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun <shijuns@microsoft.com> wrote: >> My understanding here is that we want to leverage the "push client" in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. > >Yes, this is how the spec is defined. The spec leaves it up to the implementation how to transport the information from the push server to the device. This part is entirely transparent to the webapp, even once we specify the server side of the push feature, and so is up to the implementation to do through whatever means it wants. Yes, I understand the spec is independent from how push server communicates to the device. What I'd like to get across is when the "push client" can handle generic actions already, such as posting a toast notifications, waking up the browser (or a subset of it) and let service workers to display each notification might not be the best practice from performance perspective, especially when the user does not want to pick up each incoming video call or read each incoming emails right away. It'd be great if the Push API spec allows the web developers to have flexibility to leverage the generic actions, or rely on a service worker, or maybe doing both. To folks who are interested, here is a link [1] to how the push client and push server operate on current Windows devices. As we indicated there, "power-efficient" is quite important to the scenarios. [1] http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx Thanks, Shijun
Received on Monday, 20 October 2014 02:18:57 UTC