Re: [push-api] Describe process for subscription updates (#132)

Currently the `pushsubscriptionchange` event is not specced to automatically create a new subscription, instead the spec just says:

> A Service Worker SHOULD attempt to resubscribe while handling this event, in order to continue receiving push messages.

But it's unclear how an author can "resubscribe". Should they unsubscribe then subscribe again, or just call subscribe again?

A possible process for reliably updating the subscription, even on flaky networks, would be:

1. Push service informs UA that the subscription will soon be invalidated.
2. UA wakes up SW and fires `pushsubscriptionchange`.
3. Calls to `PushManager.getSubscription` will still resolve with the old subscription for now.
4. The next time `PushManager.subscribe` is called, the subscription stored by the UA is replaced by the updated subscription, and the `subscribe` promise is resolved with this new subscription. Subsequent calls to `getSubscription` will resolve with the new subscription.
5. The website should now transmit the updated subscription to its server, retrying across restarts until it succeeds.
6. Both the old and new subscriptions are simultaneously stored by the push service, and messages can be sent using either. But once the new subscription is used for the first time, the old subscription will be deleted from the push service (after a short timeout, to allow for propagation delay in the application server(s)).
7. The old subscription will eventually expire even if no new subscription is made, or the new subscription is never used, but only after a generous grace period (weeks? months?).

Concretely, this would require changes like the following to the Push API:

8\. PushManager.subscribe method steps:
- Replace "If the Service Worker is already subscribed" with "If the Service Worker is already subscribed, and the subscription is not marked as will-be-deactivated", and make successful subscription overwrite the will-be-deactivated subscription.

11.2 The pushsubscriptionchange event:
- Replace "A Service Worker SHOULD attempt to resubscribe while handling this event, in order to continue receiving push messages" with "In order to continue receiving push messages, once this event has been received the webapp SHOULD call subscribe again, and update the subscription stored by its application server. Since the webapp may need to retry many times to transmit the updated subscription to its application server, the push service SHOULD continue to accept messages using the old subscription until messages start being sent using the new subscription".
- Replace "If the previous push subscription is still active, perform the following steps in parallel: (...) Unsubscribe oldSubscription." with "If the previous push subscription is still active, mark it as will-be-deactivated". Accordingly, `pushsubscriptionchange` would no longer need to be an `ExtendableEvent`.

See also #120 and #116.

@mvano @beverloo @gauntface @kitcambridge

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