Open CxRes opened 2 years 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.
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: