RE: Push API and Service Workers
On October 24, 2014 4:30 AM, Arthur Barstow wrote: On 10/22/14 1:21 AM, Shijun Sun wrote: I think we can take a half hour timeslot to discuss the E2E flow for the RTC scenarios using push messages. The goal is to make sure we understand the steps and options in the whole E2E story. Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27: Thanks Arthur! Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be more productive for folks having hands-on experience with Service Workers to participate. Best, Shijun [1] https://github.com/w3c/push-api/issues/84 [2] https://github.com/w3c/push-api/issues/85
RE: Push API - PushRegistration and lifetime
On Thursday, October 23, 2014 9:16 AM, Costin Manolache wrote: On Wed, Oct 22, 2014 at 10:19 PM, Shijun Sun shij...@microsoft.com wrote: It'd be very helpful if PushRegistration can have a read-only attribute for ExpirationTime or something like that. Webapps can be more proactive if the ExpirationTime is set. I agree. Okay, I'll open a bug in GitHub to track this.
RE: Push API - PushRegistration and lifetime
On Wednesday, October 22, 2014 8:41 AM. John Mellor wrote: See https://github.com/w3c/push-api/issues/74 and https://github.com/w3c/push-api/issues/82 for more details on when and why registrations might expire in a typical push service. Thanks John for the pointers! I have a few more questions. 1. When the PushRegistration expires, what are the options to notify the UA? Let's assume the case where the webapp is not active at the time. a. Should the webapp server push a special (and can be app-specific) message to the UA before the expiration? Since the webapp server manages the contract with the Push Server, it should have the best knowledge about the expiration policy. b. Or, should the Notification Server push a generic (but can be platform specific) expiration message? I don't expect the Push Server has the obligation, but would like to confirm here. I agree we should never poll. c. Or, if the PushRegistration should be renewed frequently and proactively to mitigate the issue? I don't see other options to inform the device and UA in order to trigger a pushregistrationchange event and then inform the webapp to renew or recreate the PushRegistration. 2. In case of either option 1.a or 1.b, assuming the expiration message is not dropped/lost (BTW, another flow path otherwise), I expect the SW should respond to the message and the UA doesn't have to fire the pushregistrationchange event. Is that a correct understanding? 3. Based on the current security model, in case the webapps (or maybe its SW) need to create a new PushRegistration, should the UA first get user permission (again)? All the Best, Shijun
RE: Push API - PushRegistration and lifetime
On Wednesday, October 22, 2014 9:33 PM, Martin Thomson wrote: A UA needs to be made aware of expiration or invalidation. This can be one of two ways: an explicit, prior commitment to a definite expiration, or - because I've been told that time-based expiration has issues - an explicit message from the push server indicating this event. Both mechanisms could be used in concert. Thanks Martin. It'd be very helpful if PushRegistration can have a read-only attribute for ExpirationTime or something like that. Webapps can be more proactive if the ExpirationTime is set. There's two ways to deal with this: either just surface an event to the SW (I think that costin noted a preference for this) or the UA could transparently attempt to refresh the registration and notify the SW iff the details change. So, a possible code path is that the 'change' event is fired by the PushRegistration object which is part of the SW, and the webapp will have to be active to extract the change and send the details to the webapp server. If that is correct, it's not clear to me how the SW will wake up the webapp in this case, and what the UX should be. I see no reason to require a new consent experience based on this event. This is a function that relates solely to the maintenance of the existing contract. (Note that this makes consent naturally persistent for push, which differs from things like geolocation or getUserMedia) Seems reasonable to me. BTW, I assume a browser will provide a way for user to manually revoke push registrations for specific webapps.
Push API - PushRegistration and lifetime
Folks, I'm looking for help to a couple more questions on the Push API. 1. What is the typical lifetime expected for a PushRegistration? 2. IF a PushRegistration can expire, what would be the right option(s) to renew the push service? All the Best, Shijun
RE: Push API and Service Workers
On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote: If we want to take advantage of this opportunity, perhaps you should first flesh out specific issue(s) to discuss, and then try to agree on a time + day slot in advance of the meeting. Thanks Arthur for the suggestion. I think we can take a half hour timeslot to discuss the E2E flow for the RTC scenarios using push messages. The goal is to make sure we understand the steps and options in the whole E2E story. If this is a right topic and there is enough interest in the group, I can set up a Doodle to help us pick the timeslot.
RE: Push API and Service Workers
On Monday, October 20, 2014 5:41 AM, Martin Thomson wrote: I imagine that we will permit the use of whatever a service worker has access to. Some of that is going to require prior arrangement (i.e., consent prompts might be required to enable a full screen alert, though maybe toasts). Fully agree that we should follow the same user consent requirement. BTW, I have opened a spec bug to track the topic (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27108). Thanks, Shijun
RE: Push API and Service Workers
On Sunday, October 19, 2014 6:43 PM, Jonas Sicking wrote: On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@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
RE: Push API and Service Workers
On Thursday, October 16, 2014 8:29 AM, Anne van Kesteren wrote On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@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
RE: Push API and Service Workers
On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in waking an idle device and that turns into a very long post-dial delay. People abandon calls for that sort of delay. Not saying that you are doing it wrong or anything, but just trying to set the right expectations. The RTC scenario is listed explicitly as one of the use cases in the Push API wiki [1]. I expect there is enough interest in the group. Should we allocate some cycles in TPAC to figure out details of the E2E flow? [1] http://www.w3.org/2008/webapps/wiki/Push_API
Push API and Service Workers
Hi, I'm with the IE Platform team at Microsoft. I joined the WebApps WG very recently. I am looking into the Push API spec, and got some questions. Hope to get help from experts in the WG. The current API definition is based on an extension of the Service Workers. I'd like to understand whether the Service Workers is a must-have dependency for all scenarios. It seems some basic scenarios can be enabled without the Service Worker if the website can directly create a PushRegistrationManager. I'm looking at Fig. 1 in the spec. If the user agent can be the broker between the Push client and the webpage, it seems some generic actions can be defined without the Service Workers - for example immediately display a toast notification with the push message. It is very likely I have missed some basic design principle behind the current API design. It'd be great if someone could share insights on the scenarios and the normative dependency on the Service Workers. All the Best, Shijun
RE: Push API and Service Workers
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. -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Wednesday, October 15, 2014 2:59 PM To: Shijun Sun; public-webapps Subject: RE: Push API and Service Workers I'm not an expert either, but it seems to me that push without service workers (or some other means of background processing) is basically just server-sent events. That is, you could send push notifications to an active webpage over a server-sent events channel (or web socket, or long-polling...), which would allow it to display a toast notification with the push message. So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities.
RE: Push API and Service Workers
Thanks folks for the quick responses to the questions! RE: [Martin Thomson] If I sit (as I do) with a tab open to gmail for a very long time, then it is of some advantage to me (and my network usage) to use something like push rather than websockets (or even server sent events). Besides, server sent events might be roughly equivalent, but they are horribly kludgy and suffer from robustness issues. I think Martin made a very good point. For mobile devices, it is certainly undesirable to keep the websockets for a long time. RE: [Jonas Sicking] The current design separates the trigger from what to do when the trigger fires. Which both makes for a smaller API, and for a more flexible design. That is a valid argument. To be clear, my question right now is not whether we need Service Workers in the spec. I'd like to understand how that works in typical scenarios and whether we need it in all scenarios. RE: [John Mellor] For example Android devices already maintain a persistent connection to Google Cloud Messaging (GCM) servers, so in our current prototype in Chrome for Android, we set GCM as the endpoint to which the app server sends messages, and GCM relays the messages to the Android device, which wakes up Chrome, which launches a Service Worker, and then app JS handles the message. My expectation would be the device (i.e. the push client) will pass the message to the Service Worker (when it is active), and then the Service Worker will wake up the browser. Anyway, my excuse to be new to the area ;-) Let's take the GCM example from another angle. Assuming we have a WebRTC app, which has registered for a push notification at GCM. Now there is an incoming video call, while the browser is still inactive. The notification from the web server will go to the GCM, which relays it to the device push client, which displays a toast notification *right away*, when user clicks, the browser is launched with the webapp to take the call. Is this a reasonable expectation for the E2E scenario? Would there be extra latency if we want to wait for the Service Worker to be ready (based on its schedule), which then pushes a web notification for user to take the call (or dismiss the call)? Best, Shijun
