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

I think you have pointed out the main detail I've failed to spot, if the
event.waitUntil fails to resolve then the old subscriptionId would remain
unable.
On 4 Mar 2015 18:50, "Martin Thomson" <notifications@github.com> wrote:

> 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.
>
> On 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.
>
> There 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).
>
> I think that perhaps the above should be made part of the algorithm for
> delivering pushsubscriptionchange events.
>
> p.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).
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/w3c/push-api/issues/120#issuecomment-77208351>.
>


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