Clarify static vs. dynamic structure and attributes of the connection

[pac-work]

The whole structure of transferred data seems to be very static. The GitHub repo is even ambiguous with this regards on some places. I have heard that this is by design and probably suitable enough for live production use case, but if transferring data to a cloud for the distribution purposes, this seems very limiting (audio tracks come and go, change of encoding, etc.). Also there may be changes needed in the middle of the event production while facing unforseen issues. Is the expected behavior to just over-allocated while connecting to encompass all the possible changes or should there be more flexibility?

For example, the .h file says about "GccgMediaElements": "This value must match the number of media elements configured when the connection was created using one of the ...ConnectionCreate() API functions and cannot change", but the GitHub repo says about the payload_json_str that "When transmitting, it can be use to define configurable changes to a payload" - so what are the configurable changes? The .h file stated that the structure itself isn't. Some other places in the JSON mention some other things that cannot change as well. But that probably does not mean that all the remaining parameters which do not mention anything in their JSON comments can change.

[jmailhot]

in developing the spec we tried to balance between things that can change over the span of the production, and things that ought to be constant. while its always advisable for codebases to handle change gracefully even outside the bounds of what was supposed to be change-able, we wanted to highlight changes that must be tolerated -vs- ones that should be constant. for example tolerating changes between UHD and HD would typically not be tolerated unless the session were configured for UHD, and even then it raises a ton of issues.

[pac-work]

So is the correct understanding then that: 1) Everything is expected to be static unless explicitly specified otherwise. 2) Foreseeable changes should be solved by over-allocating during the connection phase and later sending NULL inside the payload for the payload types which are currently not present. 3) Unexpected change beyond the scope of what has been agreed upon while establishing the connection requires dropping the connection (thus interrupting the signal) and re-establishing it with the new parameters (making use of GCCG problematic for the distribution use-case).

?

[jmailhot]

in negotiation (point 3) the structure has a defined minimum that everybody supports. but the level (HD, UHD, etc) can fail - the sender could be sending UHD and the receiver does not necessarily have ability to consume it. receiver can say NO.

[jmailhot]

receiver can say no.