Should single PATCH command update other streams (e.g., due to constraints)

[tianzhuqiao]

Thanks for the great project. I have a question about the single PATCH command. For example, several streams may have constraints (e.g., share the same interface ip). And if one PATCH command that changes the interface ip of one stream, should I also change the corresponding value of other streams? Or should I wait for the user to send other PATCH command to change the other streams? Looks like I couldn't find corresponding section about this in the spec. Thanks!

[garethsb]

You're correct, the spec doesn't enable a device to represent constraints between different senders and receivers so this is a product usability decision.

The specification explicitly defines an error code that means a PATCH request failed for a reason not covered by the constraints. Use that when you need to.

A 500 response may be returned if the transport file could not be parsed, or there is some failure caused by activation which was not caused by a violation of schema or constraints.

For example:

1. Is the user going to be upset if you modify an active sender? Probably?
2. How about if you modify the configuration of an inactive sender? Probably not?

For 1, you could return 500 when a PATCH to sender B would disrupt active sender A.

For 2, you could adjust inactive sender A as necessary when you get a PATCH to sender B.

[tianzhuqiao]

Got it, thanks @garethsb!

[garethsb]

@tianzhuqiao Throwing appropriate exceptions from connection_resource_patch_validator and resolve_auto are your options to implement this with nmos-cpp as far as I recall!