search

solid / notifications

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

List types in preferred order in request #15

Closed brownhoward closed 1 year ago

brownhoward commented 3 years ago

As only a single channel will be returned, I suggest that the request lists the types in preferred order just in case there is multiple overlap. In this way, the client gets their preferred type that is supported by the server.

_Originally posted by @kevin-inrupt in https://github.com/solid/notifications-panel/pull/3#discussion_r710151153_

csarven commented 2 years ago

Once a client discovers the supported subscription types supported by a notification server, the client only really needs to request the subscription type it prefers.

I'm not sure if there a significant use case to use set an order or alternative semantics where a subscription is made for each type.

If the request includes an array of subscription types, I think the notification server behaviour can be left undefined, i.e., a variable behaviour, so the server can take any one. (Unless we put stronger semantics on a valid type value but I suggest against this.)

csarven commented 1 year ago

Resolved by https://github.com/solid/notifications/pull/130 in that the subscription request data model requires one type.