{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/push-api/issues/120","labels_url":"https://api.github.com/repos/w3c/push-api/issues/120/labels{/name}","comments_url":"https://api.github.com/repos/w3c/push-api/issues/120/comments","events_url":"https://api.github.com/repos/w3c/push-api/issues/120/events","html_url":"https://github.com/w3c/push-api/issues/120","id":59786638,"number":120,"title":"pushsubscriptionchange - Initial feedback","user":{"login":"gauntface","id":139760,"avatar_url":"https://avatars.githubusercontent.com/u/139760?v=3","gravatar_id":"","url":"https://api.github.com/users/gauntface","html_url":"https://github.com/gauntface","followers_url":"https://api.github.com/users/gauntface/followers","following_url":"https://api.github.com/users/gauntface/following{/other_user}","gists_url":"https://api.github.com/users/gauntface/gists{/gist_id}","starred_url":"https://api.github.com/users/gauntface/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gauntface/subscriptions","organizations_url":"https://api.github.com/users/gauntface/orgs","repos_url":"https://api.github.com/users/gauntface/repos","events_url":"https://api.github.com/users/gauntface/events{/privacy}","received_events_url":"https://api.github.com/users/gauntface/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-03-04T11:41:51Z","updated_at":"2015-03-04T17:49:48Z","closed_at":null,"body":"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.\r\n\r\n- 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.\r\n\r\n- @jeffposnick had some concerns with respect to performing an update of the subscriptionId and endpoint when OAuth is needed to authenticate the user.\r\n\r\nI 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).\r\n\r\nIs it worth considering moving this to something that can only occur when the user is on the web page?"},"comment":{"url":"https://api.github.com/repos/w3c/push-api/issues/comments/77208351","html_url":"https://github.com/w3c/push-api/issues/120#issuecomment-77208351","issue_url":"https://api.github.com/repos/w3c/push-api/issues/120","id":77208351,"user":{"login":"martinthomson","id":67641,"avatar_url":"https://avatars.githubusercontent.com/u/67641?v=3","gravatar_id":"","url":"https://api.github.com/users/martinthomson","html_url":"https://github.com/martinthomson","followers_url":"https://api.github.com/users/martinthomson/followers","following_url":"https://api.github.com/users/martinthomson/following{/other_user}","gists_url":"https://api.github.com/users/martinthomson/gists{/gist_id}","starred_url":"https://api.github.com/users/martinthomson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/martinthomson/subscriptions","organizations_url":"https://api.github.com/users/martinthomson/orgs","repos_url":"https://api.github.com/users/martinthomson/repos","events_url":"https://api.github.com/users/martinthomson/events{/privacy}","received_events_url":"https://api.github.com/users/martinthomson/received_events","type":"User","site_admin":false},"created_at":"2015-03-04T17:49:48Z","updated_at":"2015-03-04T17:49:48Z","body":"I think that the primary concern here is the window of time between when a subscription expires or breaks and the application server is updated with new details.  A lot happens in that time potentially.\r\n\r\nOn the positive side, a lot of that can be masked by the browser, at least for expiration.  The browser can continue to maintain the old subscription until the event it delivers to the SW has been resolved (that is, if `e.waitUntil()` is used properly).  In the case of a break, the outage window is unavoidable.\r\n\r\nThere is no need to open windows, though. That would simply be bad design.  Just `fetch()` the new details to the server (ugh, that's an awkward turn of phrase).\r\n\r\nI think that perhaps the above should be made part of the algorithm for delivering `pushsubscriptionchange` events.\r\n\r\np.s., I believe that GCM does change identifiers in rare occasions (i.e., if a node crashes, but I guess that would happen very rarely)."}}