URI addressability writer use case

[jptrainor]

In regard to the MXL addressability specification:

When an MXL writer uses a URI to identify the domain and flow IDs, how is the application expected to determine which ID is video, audio, and auxiliary data? What is the intended behavior?

For example:

$ audio_and_video_writer_app mxl://dev/shm/mxl?id=8E921B1B-89C4-48C9-89E5-9FA3D6030BC1&id=C8834033-86F3-4BB3-B98B-9C9930D1EB2D&id=2582467C-633E-4E81-8CC5-2129848F9FDE

Assume in this case that audio_and_video_writer_app has all the metadata necessary to write the JSON flow definitions except the MXL domain path and the flow IDs. The application can get the domain path from the URI, but it cannot determine which ID the user wants to assign to the audio flow, the video flow, and the auxiliary data flow. It could arbitrarily assign the three IDs on its own, which is what it would have to do in this case. That may be appropriate in some cases, but not appropriate in others.

Using a specialized query key is one possible resolution to this ambiguity in the writer use case:

$ audio_and_video_writer_app mxl://dev/shm/domain?vid=8E921B1B-89C4-48C9-89E5-9FA3D6030BC1&aid=C8834033-86F3-4BB3-B98B-9C9930D1EB2D&xid=2582467C-633E-4E81-8CC5-2129848F9FDE

[garethsb]

Does a URL make sense to configure a writer at all? As you say, the writer would need already to know the parameters for its flow definitions. To me, the whole mxl URL concept seems like a very limited stopgap until the JT-DMF Flow Connection working group has defined the higher level control plane.

[vt-tv]

Does a URL make sense to configure a writer at all? As you say, the writer would need already to know the parameters for its flow definitions. To me, the whole mxl URL concept seems like a very limited stopgap until the JT-DMF Flow Connection working group has defined the higher level control plane.

correct. the addressability scheme is for existing resources. reader only for now.

[garethsb]

@vt-tv, I've lifted some notes on addressability gathered from DMF-MXL Slack channels and DMs. Is this a useful place to drop this?

The domain-path part of the URI is required and refers to the file system path in the context of the media function of the MXL domain.  The domain path may need to be translated by media functions or orchestration layer(s). For example, an MXL domain may live on /dev/shm/domain1 on a host but is mapped inside a container to /dev/shm/mxl.  This translation is outside the scope of the MXL project.

I think it should be up to a containerized or virtualized media function where the file system is rooted. The mount path may depend on the OS, storage, and be different on the host vs virtualized (container, VM) media functions. Host file system might be segregating multiple groups of domains. Etc.

You therefore can't pass an mxl: URL created by a writer media function to a reader media function (e.g. in a different container) and expect it to be able to do anything with the authority or domain-path parts. (This is not a problem specific to the proposed MXL URL. HTTP API implementations that sit behind a gateway that may remap domain/IP/port/path have a hard time publishing URLs for their own endpoints!)

In order to facilitate orchestration layers looking at flow ids exposed by media functions, a partial solution would be to inject a unique domain id into the domain visible to media functions. Could MXL orchestration write a tiny json alongside options.json? The domain path is potentially only resolvable by the media function itself, and the authority also cannot be used to identify that two mxl: URLs refer to the same domain.

If the domain id is not available, the orchestrator needs out of band knowledge of which domain is mapped to what path inside each Media Function; not a great scenario. (Compute resource orchestration and host vs. container scopes are likely managed separately than flow connection and replication.)

A domain UUID isn't enough on its own to solve the problem of Flow replication, but it more easily enables us to lift the problem out of the Media Functions, and express "please replicate Flow foo from Domain bar to Domain baz".

[jptrainor]

Thanks for the replies. That makes sense. The addressability document should mention the reader-only caveat.