Should (parts of) flow definition be available as part of the flow info or through other internal channel?

[pac-work]

Hello, I would like to ask, whether it would make sense to provide access to the NMOS flow definition used to create the flow somehow "internally" to MXL, or whether it is always expected that this type of information will be passed through some external side channel?

For example, the definition contains information like frame width, frame height and other data which may be useful for the readers of the flow. If the NMOS definition was available from the MXL directly, it would allow readers to just be supplied with the domain and the flow ID and the rest of the information they could get from MXL directly.

But maybe that would be seen just as unnecessary complication and supplementing functionality which is supposed to be provided by external flow discovery mechanism? Opinions? Has this been discussed before?

[vt-tv]

Are you suggesting something like mxlGetFlowDescriptor(mxlReader*... , const char* id....);

[pac-work]

Are you suggesting something like mxlGetFlowDescriptor(mxlReader*... , const char* id....);

I guess yes, in principle, only maybe more like:

/// Returns flow definition supplied using `flowDef` parameter when `mxlCreateFlow` was used.
mxlStatus mxlGetFlowDef(mxlInstance instance, char const* flowId, char* buffer, size_t bufferSize);

I hit this when using the reader, but in principle, as the API is structured now, writer may be somebody completely different than the one who created the flow, if I am not mistaken. That is why instance is suggested above as the first parameter instead of the reader.

[vt-tv]

Fair point. I think it would make sense and would allow some level of decoupling between the API and the physical layout of the filesystem. PRs welcomed :)

[pac-work]

I see the information is already available in <domain>/<flow_id>.mxl-flow/.json. So the API would basically just provided access to contents of that file. If that would be OK implementation, I will prepare PR when I get to it...

[pac-work]

Closing discussion, will be resolved under issue #102.