Re: Progress on Push API

On Tue, Apr 29, 2014 at 1:23 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Apr 29, 2014 at 1:17 PM, Peter Beverloo <beverloo@google.com>
> wrote:
> > Dropping a push registration has two aspects to it: (1) removing the
> mapping
> > between registration Id and the Service Worker to deliver it to on the
> > browser side, and (2) removing the registration on the push service. This
> > way we can communicate whether that has succeeded, and the registration
> Id
> > known to the site's application server has been invalidated.
> >
> > That said, an alternative would be to say that the UA would do a best
> effort
> > to drop the registration at the earliest option (e.g. when the user is
> > offline), allowing the developer to assume it succeeded.
>
> Well yes, the question is why the application cares about garbage on
> the push server. How would it handle the return value of unregister()
> other than simply ignoring it?
>

Since we only allow a single registration, register() would simply return
the current registration at least until unregister() has succeeded. A
scenario in which the developer might want to *renew* the registrations is
where their database was compromised.

>> > Promise<enumeration> hasPermission ();enumeration: Granted, Denied,
> >> > Default (or NeedToAsk)
> >>
> >> I think this can be synchronous and done similarly to
> >> http://notifications.spec.whatwg.org/#permission
> >
> > Checking whether the site has permission to use feature X is an
> asynchronous
> > operation in many browsers. In fact, I'd prefer if the Notification
> > specification would be updated to replace the permission property with a
> > hasPermission method as well.
>
> I think that ship has sailed. And setting an additional bit per origin
> does not seem too bad.
>

It would still require another synchronous operation, which is unwanted for
browsers using multiple processes. Chrome uses a synchronous IPC message
for getting the notification permission (it is not known at renderer
startup), and I would strongly prefer if we can avoid adding others.

Peter

--
> http://annevankesteren.nl/
>