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.
