PushSubscription should have an attribute for ExpirationTime about push-api HOT 19 CLOSED

Now that we define the concept of refreshing a subscription, I think it's worth to consider this again because this property would now be entirely informative.

The main argument I can come up with for this property is to enable developers to include a hard date in their data store after which a subscription should not be considered anymore (time of deactivation). That has good value for relatively little cost.

Assuming we define expirationTime as the time of deactivateion, would it confuse developers if a user agent fires pushsubscriptionchange at an earlier time to allow for some overlap?

The property would definitely need to be nullable, since not every push service will care about expiration, or be in a position at which they can indicate this. That's probably OK.

from push-api.

This might be useful, do you have a concrete use case in mind? Note also the pushsubscriptionchange event which may be used to indicate to the webapp when to refresh the subscription. I'm concerned this might overlap.

Note that, if exposed, this should most likely be made consistent with issue #81 (Consider exposing meta-information on push message)

from push-api.

Use case: The webapp, when it is active, can check the expirationTime and update the subscription proactively. The webapp can make the decision based on whether it is close to the expirationTime.

from push-api.

It seems valid, but how is it different from pushsubscriptionchange? Is the difference important enough to expand the API?

Note also that pushsubscriptionchange is more general, it can handle other reasons for refreshing the subscription e.g. if we later added encryption (issue #55), it can be fired because the encryption key was rotated.

from push-api.

The pushsubscriptionchange event is great when the device is powered on at the right time and is on the network to receive the push server subscription expiration message.

There is another assumption that the device is always able to launch the Service Worker and possibly the webapp to complete the subscription update operation, which likely involves a trip to the web server. Otherwise, the service might be interrupted.

Giving more info to the webapp will help developers make better decisions for the user experience.

It might be helpful to think along the same direction for the encryption case.

from push-api.

Those challenges (availability of battery, CPU, memory, network, device being on at all) are real. Most of these apply to any solution of course.

I think there is also an argument in favor of pushsubscriptionchange: the user agent controls when to fire it. As the user agent knows more about the state of the device and its resources, it can select a more suitable time to refresh the subscription. The event can also be fired more than once, in case refresh failed.

A second advantage of the event based approach is that it can be run in the background, at a time when the app would otherwise not be running at all.

from push-api.

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.
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?

from push-api.

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

from push-api.

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).

from push-api.

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.

from push-api.

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.

Certainly not a YAGNI. We have the expirationTime value exposed on the Windows platform since Win8. We are contributing here based on our experience with windows developers.

from push-api.

Yes, but my reading of the Windows API[1] is that developers are responsible for refreshing the channel. That makes this value critical. On the other hand, if the refresh is done for you, the need diminishes greatly.

[1] http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.pushnotifications.pushnotificationchannel.aspx

from push-api.

I think the fundamental question to us is still whether the refresh can be guaranteed at all time and whether the expirationTime can help. So, let's focus on a special case for now.

The target device is off or out of network so there is no guarantee that it will receive the expiration message from the push server. There is a blackout period before the subscription is refreshed completely.

I see at least 2 possible solutions. One is to expose the expirationTime so the webapp can refresh accordingly. The other is to keep a hidden expirationTime (as Michael mentioned) and fire event by the user agent, of course there is a question when to fire since the user agent doesn't know whether the expiration message is lost or not. The first option seems better to me. But, please feel free to expand here and add other solutions you might have in mind.

from push-api.

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).

from push-api.

It's cool to think forward for new push server/service operations. Meanwhile, let us make sure the API support existing services and devices.

from push-api.

Sorry, clicked a wrong button. Now issue reopened.

from push-api.

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 [email protected]
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
#86 (comment).

from push-api.

I think we should aim to keep this API as small as possible in order get multiple compatible implementations sooner. I'll mark this as a potential v2 enhancement.

from push-api.

+1 for the semantics proposed by @beverloo. In addition to the potential benefit from the developer perspective, the deactivation concept will allow push services to gracefully remove subscriptions, which the apps decided not to actively manage within an extended period of time. This could also be applicable to a website that a web user stopped visiting for quite a while.

from push-api.