[push-api] pushsubscriptionchange - Initial feedback (#120)

After talking with @johnmellor and @jeffposnick on different occasions a few concerns have come up that may be worth discussing the appropriate approach from a developer approach or see if the API simply is the best approach.

- It feels like the pushsubscriptionchange event results in a somewhat poor experience for the user if there is any kind of error. If the subscription changes, the developer re-subscribes (assuming the permission state has changed), tries to send this to their server, that fails for whatever reason, now the developer has no way out other than to wait for the user to visit their page again in the hope that they can then send the new subscription.

- @jeffposnick had some concerns with respect to performing an update of the subscriptionId and endpoint when OAuth is needed to authenticate the user.

I understand that in Chromes current implementation this isn't a problem since GCM doesn't have a need to change the subscriptionId (at least to the best of my knowledge), but for future implementors, this feels like the API will result in a number of bad patterns by developers or poor experiences for users (i.e. randomly opening windows to update the subscription details OR the user simply not getting the push messages because the subscription could be updated on the server).

Is it worth considering moving this to something that can only occur when the user is on the web page?

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