Currently, it's only ColorConfig::createLookTransform and createDisplayTransform that take the key/value pair, so it's only those two that would need new varieties added. Not a big deal to add two methods. (Reality check: right now, createColorProcessor doesn't take any key/value parameters, and I'm not 100% sure if that's because the underlying OCIO functionality doesn't need them, or just that nobody has ever asked for it from me. Do you know? Should we be adding key/value to that as well?)
I like sticking with #3, too, as it certainly makes things simple because it adds no new API calls, and the common 0-key and 1-key cases don't change at all. But I admit it's a little quirky. Do you believe that the comma as separator will be no problem? Nobody would have key or values names that themselves needed a comma embedded in them? > On Oct 23, 2016, at 4:00 PM, Jep Hill <[email protected]> wrote: > > Thank you for the options. > > Options 1 and 4 have the appeal of keeping the key/value pairs together; and > of the two, I do like option 1 for the fact that it’s foolproof. However, > wouldn’t this require adding a new version to each OCIO related function? > > Option 3 would be backward compatible and I’m tempted to lean toward it since > we’re only talking a handful of keys and values. > > My $0.02 — looking forward to your thoughts. > -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
