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

I'm on the fence on this issue.  Expiration information definitely needs to be available to the user agent, but the question here is whether it needs to be available to applications.

On the one hand, having the user agent automatically refresh the subscription (assuming that there is some sort of expiration of the subscription), is easiest and best.  They can use push-service-specific knowledge or knowledge about radio states to ensure that refreshes are properly coordinated and efficient.  I don't want applications driving the refresh process.  In this model, all that an application sees is the occasional `pushsubscriptionchange` notification, assuming that any subscription info has changed.  Note also that reducing the information in the subscription also reduces the potential for `pushsubscriptionchange` notifications, which is a small advantage.  The fewer reasons we have for waking the SW, the better; it also reduces load on application servers who have to be notified when anything changes.

On the other hand, having this information available to an application can avoid problem when it comes to requesting push message delivery.  Applications could simply not bother to use expired subscriptions.  However, if it is important information, it would be bad if applications end up using flaky heuristics to decide when a subscription has expired: "this is a *.microsoft.com endpoint, they typically expire after 4 days".

I think that my relatively weak preference is to avoid the inclusion of the property solely on YAGNI grounds, but I think that I could be easily convinced otherwise.  Especially if an application developer has experience that suggests that the information is valuable to them.



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