Rename (un)register to (un)subscribe

[johnmellor]

@costinm mentioned that it would make more sense to use the term (un)subscribe instead of (un)register, since the app is not registering for an account, instead it's subscribing to a source of messages (this also matches better with terminology like Pub/Sub).

[martinthomson]

I've started using the terms subscribe/unsubscribe after discussions at the IETF around terminology. This is better, in my opinion, since it fits the messaging model better. Of course, none of the other SW APIs do that. What do you want consistency with? Unless of course, we can change the naming used elsewhere...

[johnmellor]

The other SW APIs are less related to messaging though, so perhaps it's ok to be named differently? i.e. perhaps the following is actually fine?:

navigator.serviceWorker.register(...);
navigator.serviceWorker.ready.then(registration -> {
    registration.pushManager.subscribe().then(...);
});

I suppose it does conflict a little with the serviceWorkerRegistration.syncManager.register API currently suggested for Background Sync in WICG/background-sync/issues/20, though there's still time to change that.

[jkarlin]

I don't think that subscribe/unsubscribe makes sense for Background Sync.

[mvano]

I don't feel very strongly about subscribe and subscription vs register and registration. The churn in spec, implementations, and demos seems hardly worth it.

Subscribe may seem nice when phrased as "subscribing to a source of push messages" but it also seems a little weird as you don't even specify the source that you are subscribing to. You're acquiring an endpoint to which any number of apps can send messages, and it has an id. It seems like "register" and "registration" cause very little confusion as a name for these concepts.

In favor of sticking with register: it retains consistency with the Service Worker, Sync, and Geofencing APIs.

CC @jakearchibald for the Service Worker perspective

[beverloo]

Churn in the specification and/or demos for something that hasn't shipped anywhere yet really isn't an argument. There are no backwards compatibility concerns here.

I think that describing this as "subscribing to a push channel" makes sense -- the user is essentially subscribed to receiving a flow of messages from the push service. I'd be in favor of doing the rename.

[martinthomson]

If this isn't renamed, we're going to have a problem with the protocol.

[mvano]

Looking at the latest web push protocol draft [1] I see now that it uses both terms. I agree that subscribe/subscription is the better term to use as it maps to the concept of the same name in the protocol.

I'll take a look at making this change in the Push API spec.

[1] https://martinthomson.github.io/drafts/draft-thomson-webpush-http2.html