- From: John Mellor <johnme@google.com>
- Date: Fri, 11 Jul 2014 17:29:49 +0100
- To: Jake Archibald <jaffathecake@gmail.com>
- Cc: Webapps WG <public-webapps@w3.org>
- Message-ID: <CAG_kaUafXvq9rNV11fzuSj2QRud15WfAnkMDt2YGiW603eKWHw@mail.gmail.com>
Yes, moving push (especially register, unregister and isRegistered) onto ServiceWorkerRegistration instances would make the API a lot easier to use. Currently it's order dependent, and if a developer tries to register before they have registered a Service Worker, navigator.push.register will reject the promise (as there will be nowhere to deliver the messages to). We talked in the past[1][2] about moving these methods to Service Worker instances, but at the time there was no equivalent to ServiceWorkerRegistration so this stalled. It doesn't make quite as much sense for hasPermission as it does for the other three methods (since you could conceivably want to only install a Service Worker if you will have permission), but that seems a worthy casualty in exchange for stopping developers shooting themselves in the foot with the other methods (and perhaps would be best addressed by standardising some separate API for seeing what permissions are granted to the webpage, rather than having every spec invent their own). [1]: https://github.com/telefonicaid/WebAPISpecs/issues/30 [2]: https://github.com/w3c/push-api/issues/2 On 11 July 2014 16:17, Jake Archibald <jaffathecake@gmail.com> wrote: > Currently serviceworker-dependent APIs are sitting in navigator.whatever, > but now we're adding a ServiceWorkerRegistration object ( > https://github.com/slightlyoff/ServiceWorker/issues/365#issue-37477775) > it feels like they should live there. > > So instead of: > > navigator.serviceWorker.ready.then(function() { > navigator.push.register(...) > }); > > it'd be: > > navigator.serviceWorker.ready.then(function(reg) { > reg.push.register(...) > }); > > This should make it clearer that push registrations are dependent on the > serviceworker registration. Meaning each serviceworker can have its own > push registration, and unregistering a serviceworker means the push is > unregistered with it. > > We're also discussing introducing > navigator.serviceWorker.getRegistration(docURL), allowing developers to get > any serviceworker registration on the origin. This means a page like > "/config/" could register/unregister push for other parts of the origins > ("/calendar/", "/messaging/" etc). > > Does that sound reasonable? >
Received on Friday, 11 July 2014 16:30:34 UTC