RE: Push API - PushRegistration and lifetime

2014-10-23 Thread Shijun Sun 
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

2014-10-23 Thread Martin Thomson 
On 22 October 2014 22:19, Shijun Sun shij...@microsoft.com 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.

RE: Push API - PushRegistration and lifetime

2014-10-22 Thread Shijun Sun 
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

2014-10-22 Thread Shijun Sun 
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

2014-10-21 Thread Shijun Sun 
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