Jeremy Selan <jeremy...@...>
Ok, I'm convinced. Let's give YAML a shot.
In terms of broad technical strokes, I think either YAML or XML would
be sufficient. But given your enthusiasm for YAML, and it's superior
human readability, there's no argument against it. (Other than the
work / support involved).
A few additional comments as we get going:
* This will break the API, so before I roll the commit(s) into the
master branch we'll tag off a stable 0.6 branch. Feel free to do
anything you want in your local git branch, of course.
* As we introduce OCIO "dynamic" Transform plugins, my hope is to not
burden them with the task of serialization. But let's not worry about
this for now.
* I agree that Yaml-cpp seems like our best option of the ones you've
mentioned. Let's go with it. Is is feasible to wrap it into the
OCIO namespace? see src/core/tinyxml/tinyxml.h as an example It's
got a lot of source files, but I really would prefer if possible to
keep all OCIO symbols inside a versioned namespace.
* For the OCIO:Config implementation, the list of display devices and
color spaces actually do preserve order. While the ordering is not
relevant to color processing, it is useful in a UI context.
* Keeping the serialization code internally as statics - not on the
Transforms themselves - is useful so we dont need to expose the
serialization to the public API. Or do you have a better
implementation in mind?
As soon as you have even a stub implementation -- it doesnt need to
build -- I'd love to see it!
Thanks for all your work on this issue,