Re: Push API - PushRegistration and lifetime
On 21 October 2014 12:14, Shijun Sun wrote: > 1. What is the typical lifetime expected for a PushRegistration? mu. There's only the expectation that the registration is useful. > 2. IF a PushRegistration can expire, what would be the right option(s) to > "renew" the push service? They certainly can expire, but the idea is that you would receive some notification (currently badly named `pushregistrationlost`) when that happens.
Re: Push API - PushRegistration and lifetime
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. On 22 October 2014 16:33, Martin Thomson wrote: > On 21 October 2014 12:14, Shijun Sun wrote: > > 1. What is the typical lifetime expected for a PushRegistration? > > mu. There's only the expectation that the registration is useful. > > > 2. IF a PushRegistration can expire, what would be the right option(s) > to "renew" the push service? > > They certainly can expire, but the idea is that you would receive some > notification (currently badly named `pushregistrationlost`) when that > happens. > >
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 22 October 2014 14:17, Shijun Sun wrote: > 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 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. > 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? 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. > 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)? 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)
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.
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 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 22 October 2014 22:19, Shijun Sun wrote: > 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. I was thinking that this was a protocol concern primarily and that the UA would be the best place to be proactive. As Costin points out, if we get individual apps being proactive, they won't know about whether the radio is on, and they won't coordinate properly. I think that I'd prefer to have the UA consume any expiration information and not expose it in the API.
