On Tue, Apr 29, 2014 at 1:23 PM, Anne van Kesteren <[email protected]> wrote:
> On Tue, Apr 29, 2014 at 1:17 PM, Peter Beverloo <[email protected]> > 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/ >
