W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: [push-api] Moving "PushManager push" onto ServiceWorkerRegistration

From: John Mellor <johnme@google.com>
Date: Fri, 11 Jul 2014 17:29:49 +0100
Message-ID: <CAG_kaUafXvq9rNV11fzuSj2QRud15WfAnkMDt2YGiW603eKWHw@mail.gmail.com>
To: Jake Archibald <jaffathecake@gmail.com>
Cc: Webapps WG <public-webapps@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC