Re: [push-api] PushSubscription should have an attribute for ExpirationTime (#86)

Hi Michael, I'm thinking more of a combined solution, rather than replacing the event mechanism at all.  I might not have made it clear.  I agree with you, also as implied in my original proposal, the expirationTime might not be always available at all time, so can be nullable.  It's great that you see a value in keeping at least a hidden expirationTime.  It would give flexibility to the webapp for the same reason you described for the user agent.

Re the example
> If the third step fails to resubscribe (e.g. due to a flaky network, or the user agent was killed), the push service will know that there's still something wrong with the subscription. I think we should allow the user agent to fire the event again later in such cases.

I think we would need an algorithm in place to define how long a subscription should be kept by the user agent after it expires if the user agent need to fire events again at a later time. It might be even trickier if multiple subscriptions are allowed from the same webapp, which can create a new subscription instead. As long as the subscription object is available to the webapp, I think the expirationTime is a useful info to the webapp (even when the subscription has expired).  

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/86#issuecomment-70557934