Added configurable delimiters for parseColorSpaceFromString()

[mike1158]

I went ahead and made a pull req. based on the discussion in ocio-dev (https://groups.google.com/forum/#!topic/ocio-dev/dfOxq8Nanl8)

[Shootfast]

Hi, just wanted to say I haven't forgotten this. I'll run through the changes soon and hopefully merge this. Sorry for the slowness!

[mplec]

Any life left in this one? We are running into the same problem and this would be a big help. We can patch locally but it seemed like there was plenty of support in the original discussion (https://groups.google.com/forum/#!searchin/ocio-dev/strictparsing/ocio-dev/dfOxq8Nanl8/TgdFL-2q6c8J). Was there any reason not to merge this?

Thanks,
Matt

[malcolmhumphreys]

Sorry that it took so long to get back to this.

Do you think that delimiters would be used else where in OCIO? I would either lean towards being more verbose in the API name or use YAML markup to be an actual list vs a packed string.

@mike1158 I hope you still care about this. @lgritz / @mplec it would be good to get your thoughts on this as well.

[mplec]

I don't have specific use cases for using delimiters elsewhere but it's not hard to imagine parsing other ocio config-defined names from strings, maybe display names from a string, something like that. But I'm just speculating. Splitting out the check for being delimited that was implemented in the PR to a function like isDelimited(substring, string) might be cleaner and more likely to get reused instead of unintentionally reimplemented?

On the YAML list vs packed string, I don't have any strong feelings. However a list would future proof if the delimiter ever needs to be more than a single character. That seems worth something.

Another question that popped into my head on re-reading is do we care about different delimiters before and after? I can't think of a case where I need that now but maybe someone else can? However at some point you're trying to accommodate everyone's pipeline quirks in a library convenience function that should be simple and cover 80% reliably and beyond that we can just do our own pipeline-specific parsing knowing how we name things, as we're doing now.

[malcolmhumphreys]

Please see new pull request #413

[michdolan]

Curious if we feel like the new OCIO v2 file rules section solves this adequately. It's a different solution, but since it supports wildcards and regex it is more flexible. @hodoulp @doug-walker do you think it would be useful to support a special ${name} variable or similar in file rules regex strings to imply the placement of a color space name, rather than needing to have a pattern that accounts for every color space naming convention?

[doug-walker]

It's not clear why this PR is still open given that it was superseded by PR #413. Should we close this one? Michael, I will respond more fully to your question in the newer PR.

[michdolan]

Closing to continue discussion on how this could be realized in OCIO v2 in PR #413 since color space parsing functionality has been rewritten since this was opened.