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

I think exposing and documenting some timeouts is quite useful, but it's
more than 'subscription' timeout that may be relevant:

1. for services that store messages for offline devices - how long will
they be stored if the device doesn't connect ( 3 weeks for GCM for example )

2. how long will the push service keep accepting incoming messages for
devices that have not been seen in a long time.

3. how long the push service will keep record of a particular device ( for
privacy and storage the service may delete all records associated with such
device )

It would be good for the spec to mention such cases may exist and some way
to discover the limits.



On Tue, Jan 20, 2015 at 3:42 PM, Martin Thomson <notifications@github.com>
wrote:

> If a subscription expires while a device is offline, it can always learn
> about the event when it wakes up.
>
> If we assume some sort of session-based interaction between the UA and
> push service, then re-establishing that session after a long period offline
> is common. At that point, the push service can inform the UA of the absent
> session. That provides a pretty good trigger for UA-based refresh and any
> necessary events.
>
> All that an expiration time does here is reduce the number of attempts
> from the application server to request pushes. But that number can always
> be reduced to one by having the push subscription endpoint return a
> terminal error code (like 410 Gone).
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/w3c/push-api/issues/86#issuecomment-70757926>.
>

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