AcademySoftwareFoundation
Support for name/value pairs
As part of the discussions around issue #1975, there has been a side discussion around allowing arbitrary name/value pairs. For example, many file formats allow some sort of capability like this to store metadata. OpenEXR is one example.
However, an OCIO config is not really an asset format, like an image file, so different considerations apply.
In addition, features like this can easily become unwieldy. It's difficult to keep people aligned on maintaining consistent usage. We've already seen this in OCIO with the roles mechanism where the usage has been so inconsistent that it's difficult for applications to use it for many of the things it was intended for without declaring their own private set. (Roles have been a bit of a train wreck, IMHO.)
And there may be security risks or performance issues if people are allowed to use this to include binary blobs (e.g., encoded using base64 or something similar that would work in YAML).
As with both OCIO roles and OpenEXR attributes, it would be possible to use some sort of namespace convention to organize names into groups. The namespace would indicate what organization owns the semantics for that name/value pair.
This issue is to capture specific use-cases for how people would expect this feature to be used and what applications would be expected to do with it.
Hello,
This is something that comes to mind when I see topics like: https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/2153 https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/2152 https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1975
Not that any of them are invalid, but it does raise the question in my mind if an explicit API is required for every request (and future requests). Especially where the API doesn't do much more than return the value in that field.
A generic and stable get/set API for metadata seems like it would be worth it, if only so we don't get long delays between features as API consumers slowly update and config-duplication that comes with it from a studio side.
I'm not sure why Roles are cited as a failure. They have enabled and solved a large swath of problems that never made it to GitHub issues because users could solve them themselves. Perhaps a failure being the concepts they encapsulated were not evolved since the late 00's workflows.
Opening the door to enabling users to bootstrap solutions without waiting for API "permission" can expose well worn paths that would then be interesting to nail down into the API, but even then it could be done via "sanctified" keys via ENUMS, so old/new configs could simply adopt the keys before a specific API version supported them.
In summary, I think generic interfaces enable dynamic problem solving and more robust forward/backward compatibility. Answering the fear of unstable systems with rigged semantics does have a place as well, but I tend to feel that chiseling first steps in API stone will lead to more brittle systems as the world around them evolves.
Hi Sean! Here's how I'm currently thinking about this....
The three fields for the three tickets you link are referencing distinct things that link directly to a color space. They are also in the case of ICC and AMF established standards, and the interop_id is something we'd like to see rise to that level someday. Therefore, top level attributes seem like the clearest and cleanest way to go.
If we want to go further in the future and incorporate other fields, we could still go the direction of using an external metadata library or having a "general" key value pair item list, or if we decide to, continue adding bespoke items as needed.
I don't believe that adding these three now preclude us from doing other things in the future, especially as they are not required items. I do believe taking this small step now will enable us to test the ecosystem, foster adoption, etc. such that when we do more, we have set up a system in which to percolate these changes.
I think I agree with Sean.
it could be done via "sanctified" keys via ENUM
And I think this approach would quite well.
Dumb idea... maybe we could use .ociom files to override / additionally store interop_id-indexed key/value pairs? This could be a quick and dirty way to "wrap" arbitrary configs in an ultimate layer of key/value metadata outside the constraints of config-ocio-version-compatibility, if that makes sense.
