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

Hi Shijun, I'm trying to see whether expirationTime, the event, or a combination of both is useful. So far, I think the event is the more versatile solution, and the attribute seems to handle fewer cases.

> It seems there are a few assumptions here already - for example, the user agent received the "expiration" message already so can fire the event at a later time.

Yes, but that's the same amount of information as required by an expirationTime attribute, it requires the user agent to already know that time and date. The implementation for the event is more flexible though. The user agent could, as an implementation detail, have a hidden expirationTime attribute and use that to decide when to fire the event. Or, again as an implementation detail, it could have received an expiration event from the push service just a moment ago. There are cases where a subscription expires at an unpredictable moment, for example because someone decided to invalidate it after a security incident e.g the subscription details were leaked.

Note that some push services may not have a defined expiry date for subscriptions (it is open ended). See [1].

> Another one is that the user agent can select a time to refresh the subscription and will know whether a subscription refresh failed or not - basically also assuming the webapp will always refresh the subscription?

The user agent does know if the subscribe call fails, that's when it rejects the promise. But, the source of truth about subscriptions lives in the push service, not the user agent or the web app. The push service would inform the user agent about expiry of subscriptions. The proposed webpush protocol describes this in [1].

So for example:
1. The user agent learns from the push service that a subscription will soon, or has already, expired.
2. The user agent fires the pushsubscriptionchange event.
3. The webapp (code in its service worker) calls subscribe to get a new subscription.
4. The webapp sends the new subscription details to its app server.

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. The expirationTime attribute might also be helpful here, as the next time the webapp runs it can check for it. But, the user might not open the app for some time.

If the fourth step fails to store the new details in the app server (e.g. due to a flaky network, or the user agent was killed) I think both the event and the attribute don't help much. I can see various ways of recovering from that though.

[1] https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html#rfc.section.7.3

CC @martinthomson @costinm

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