solid / notifications

Solid Notifications Technical Reports
https://solid.github.io/notifications/protocol
MIT License
11 stars 7 forks source link

Rename Subscription Client #142

Closed CxRes closed 1 year ago

CxRes commented 1 year ago

With the redesign of the Notification Protocol, "Subscription Client" is no longer appropriate nomenclature. For, our client might connect to a pre-existing notification channel without establishing a subscription at all.

I am not sure what to call it other than "Client". Perhaps "Discovery Client" might work too.

csarven commented 1 year ago

Open to another term that better matches the current role and functionality of SubscriptionClient, i.e., one that can use a notification channel in addition to going through the subscription flow. SubscriptionClient shouldn't further be split into separate products - I'm aware that's not what you are proposing here.

It is reasonable and practical to have a product that should be able to go through subscription as well as using a notification channel. From that perspective, I think the term SubscriptionClient is okay, and leave it at that. I don't think for example DiscoveryClient is adequate because that doesn't seem to quite capture the functionality besides the discovery step.

NotificationClient may be a broader term with some concern that it may add some confusion alongside NotificationSender and NotificationReceiver.

ChannelClient feels a bit strange.

CxRes commented 1 year ago

I also do not want to split the product and do not like NotificationClient for the same reason as you. But if you find ChannelClient strange, then SubscriptionClient is equally strange.

Thinking about it a bit more, the best terms I can come up with (for now) are:

Hopefully, the group will come up with a better suggestion!

uvdsl commented 1 year ago

I think that the Subscription Client's main job is to establish the subscription / notification channel for whomever, potentially itself, to receive notifications. The fact, that the client can also pick up an existing notification channel (for whomever to receive notifications, potentially itself) without going through a new setup phase does not change it in term of functionality. The setup is simply omitted. So I find the naming still to be appropriate.

csarven commented 1 year ago

(Notification) Manager Client may be another term that could work. I still think Subscription Client fits.

I'd like to know what @elf-pavlik @acoburn thinks about this proposal or have other thoughts.

elf-pavlik commented 1 year ago
sequenceDiagram
  participant Discovery Client
  participant Resource Server

  Discovery Client ->> Resource Server: HEAD Resource (topic)
  Resource Server ->> Discovery Client: HTTP Link rel="describedby"
  Discovery Client ->> Resource Server: GET Description Resource
  Resource Server ->> Discovery Client: Description Resource
sequenceDiagram
  participant Subscription Client
  participant Subscription Server

  Subscription Client ->> Subscription Server: Subscription Request
  Subscription Server ->> Subscription Client: Subscription Response (with Notification Channel)