source_id and flow_id confusion

[garethsb]

Follow up to #32 and #33.

According to Core models, each Sender is uniquely associated with a Source and a Flow (as per the NMOS Content Model). But according to Transport - Websocket - connection_uri, multiple Senders will share the same "connection_uri", and the subscription command allows multiple Sources to be requested. The WebSocket connection thus actually combines multiple Flows.

How then are the "source_id" and "flow_id" meant to be set in the "identity" in the WebSocket message?

[garethsb]

For reference, "flow_id" was added by @mjeras in response to @andrewbonney item 11 in #14 (comment), but the problem applies equally to "source_id" doesn't it?

[garethsb]

Ah, I see partly why I was confused. Although IS-04 Query WebSocket API may batch multiple events into one message, IS-07 doesn't do that. Therefore the "source_id" and "flow_id" in the message apply to a single event, which does correspond to a unique Source/Flow.

The state message type now makes sense to me.

Does this mean that a WebSocket connection subscribed to multiple Sources will get a reboot/shutdown/connection_lost message for each Source when those events occur in most cases?

[garethsb]

Does this mean that a WebSocket connection subscribed to multiple Sources will get a reboot/shutdown/connection_lost message for each Source when those events occur in most cases?

As discussed on the call, yes, this is the intention, since Sources may potentially shutdown independently.

I hope the changes in PR #44 to Transport - WebSocket which attempt to clarify that Flows from more than one Source may be carried by a single WebSocket connection are enough to avoid other people having the same original confusion!