- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 29 Apr 2014 13:23:11 +0100
- To: Peter Beverloo <beverloo@google.com>
- Cc: EDUARDO FULLEA CARRERA <efc@tid.es>, public-webapps <public-webapps@w3.org>
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? >> > 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. -- http://annevankesteren.nl/
Received on Tuesday, 29 April 2014 12:23:38 UTC