Add C++ docs to repository

docs/cxx/bridges.md

@@ -0,0 +1,46 @@
+# Language Bridges
+
+## Python
+
+Since OTIO originated as Python (and has an extensive test suite, in Python),
+our starting position is that existing Python code (adapters, plugins,
+schemadefs) should continue to work, as currently written, with as few changes
+as possible. However, in anticipation of the rewrite of the core in C++, some
+changes are were made proactively made to ease this transition.
+
+For example, the Opentime types (e.g. ``RationalTime``) have value semantics in
+C++, but reference semantics in Python, which has actually been a source of
+bugs.  Recent changes to the Python code have made the Opentime classes
+immutable, to ease the transition to them being entirely value types in C++.
+
+Python code in the `core` or `schema` directories were rewritten, but Python
+code outside those modules should required little (or in some cases no)
+changes.
+
+The bridge from C++ to Python (and back) is `pybind11`.  Given that existing
+code needs to work, clearly, the bridge is implemented so as to make the
+reflection of the C++ datastructures, back to Python, utterly "Pythonic."  (It
+has to be, since we didn't want to break existing code.)
+
+## Swift
+
+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 `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)
+
+Bridging 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.
+
+
+