Re: [w3c/push-api] Retry push event (#300)

>  You want multiple activations from the same push message. 

Yes, I mean you should retry if an exception is triggered inside the `push` event. 
If I understand the spec correctly, you can extend the existing retry mechanism (Section 11.2.2 point 7) to this use case:
when an exception occurs inside the `push` event, you can simply avoid to acknowledge the reception of the push message to the *push service*, so that the delivery will be retried after some time.

>  @beverloo was on the right course with the mention of background sync

That may conflict with `userVisibleOnly`... I don't know if showing a notification in the `sync` event  (and not inside the `push` event) will be considered a notification displayed by the browser. Also, I don't know if the browser can display notifications to the user from a `sync` event...

And in any case the background sync would only prevent network problems, while a retry on exceptions would also make `push` resistant to application server errors (e.g. you can raise an exception if you receive HTTP 503 in order to force a retry). Without a retry mechanism, you will always loose the processing of a percentage of push events due to temporary exceptions, thus making this technology unreliable.

>  if the application server is down, you register with background sync to be awoken again after some time.

If I understand the spec correctly background sync will only allow to delay the execution until you get an internet connection. It is not meant as a way to execute retries for arbitrary exceptions... so you cannot use it to make your code resistant to *application server* errors (e.g. 503).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/300#issuecomment-418324511