Proposed Language Bridges¶
Since OTIO originated as Python (and has an extensive test suite, in Python), our starting position
is that existing Python code (adapters, plugins, schemadefs) must continue to work, as currently
written. Python code in the
schema directories will of course be rewritten, but Python code
outside those modules should not be aware of any change.
The bridge from C++ to Python (and back) will be
pybind11. Given that existing code needs to work,
clearly, the bridge will be implemented so as to make the reflection of the C++ datastructures, back
to Python, utterly “Pythonic.” (It has to be, since we don’t want to break existing code.)
Given the above, there’s no point giving Python illustrations of how things will work going forward: they’ll work as they already have.
The intention is to expose OTIO in Swift with the same care we take with Python: we want everything
to feel utterly Swift-like. Because Swift can gain automatic API access to non-member
functions written in Objective-C++, and Objective-C++ can directly use the proposed OTIO C++ API,
we believe that a bridge to swift will not require writing
an explicit explicit
extern "C" wrapper around OTIO C++.
We believe that like Python, Swift should be capable of defining new schemas,
and that access to existing and new schemas and their properties should
be done in terms of Swift API’s that conform Swift’s sequence/collection protocols,
just as Python interfaces do with respect to Python.
Bridging to C (and other languages)¶
Briding to C (and by extension other languages) would presumably be accomplished
by writing an
extern "C" wrapper around the OTIO C++ API. This is of relatively
low priority, given that we will have three languages (C++ itself, Python, and Swift) that
do not need this.