solid / notifications

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

Cases where Client might want to update Subscriptions/Connections #103

Open CxRes opened 2 years ago

CxRes commented 2 years ago

Depending on the application, clients might want to update subscriptions and/or create/destroy connections. This issue is meant to track these cases, since such updates inform the design of the protocol.

Let me start with cases which I care about:

  1. Client might want to change features. For example, client might want to slow down the rate of updates based on user activity.
  2. Client might want to add or remove resources to watch (assuming we allow multiple resources on the same subscription) based on a top level container they are watching. These updates might even be recursive.
csarven commented 1 year ago

The user may want to extend the period of an existing subscription without necessarily requesting a new one. I can see this use case but the solution may not necessarily need a special request that alters an existing subscription. Simply put, a new request can be made with a desired start time (as the previous one ends) and a new end time. It would also be simpler for the subscription server to handle a new request than to update an existing one, especially considering if the originals should be kept for audit.

I'm thinking that in this particular case, updating a channel will require more mechanical parts, e.g., tracking patches of a particular resource, than keeping the available channel as snapshot.

I'm not sure if that can be generalised to a point where the other cases may also be subject to same considerations, but I like the idea of treating things as immutable (as possible) instead of mutable.