Re: Progress on Push API

Domenic wrote:
> this doesn't allow notification that you need to re-register

I was trying to make the point that events letting the webapp know it needs
to re-register should go to the Service Worker, so the webapp can
re-register whether or not it happens to be currently open. Since the app
might not be open at all, Promise-based APIs don't work, as Promises can
only persist as long as their JS context stays alive, hence PushError being
an event delivered to the SW.

> be sure to only use rejections for exceptional situations [2]. It wasn't
clear in your message, John, but you seemed to be proposing that
isRegistered() reject when not registered?

No, I was saying that isRegistered would resolve the promise with true or
false, except if the UA for some reason couldn't determine whether the
webapp had registered yet, in which case it would reject the promise. But
perhaps a) UAs can always determine this, or b) in such cases it would be
better to just wait until the UA becomes able to determine this, in either
of which cases some kind of registrationRequired promise would be easier to
use.


On 2 May 2014 16:17, Domenic Denicola <domenic@domenicdenicola.com> wrote:

> Regarding promise idiomaticness, the two proposals I've seen that look
> most reasonable would be:
>
> - isRegistered() + register(). But, this doesn't allow notification that
> you need to re-register, from what I can tell.
> - A variant on registrationNeeded, where---since it can return a different
> promise each time---it becomes a method, named e.g.
> waitForRegistrationNeeded() or whenRegistrationNeeded().
>
> The former is a very typical async-function-call use of promises. The
> latter is the notification-of-state-transition use of promises [1], which
> is a bit less typical, but is often convenient---especially, as Jonas
> notes, when you would want to find out even after the fact.
>
> Also, be sure to only use rejections for exceptional situations [2]. It
> wasn't clear in your message, John, but you seemed to be proposing that
> isRegistered() reject when not registered? That would be a promise
> antipattern, akin to a synchronous function called isRegistered() throwing
> an exception to signal non-registration.
>
> [1]: https://github.com/w3ctag/promises-guide/issues/25
> [2]:
> https://github.com/w3ctag/promises-guide#rejections-should-be-used-for-exceptional-situations
>