Projected library usage patterns

OpenAssetIO Projected library usage patterns

This page covers details of the various scenarios in which we foresee OpenAssetIO being used within other projects.

A: Integration into C++/Python Qt desktop application

As a

• Existing Qt application based around a QApplication.
• Cross-platform Win/*nix
• Built to some variation of the VFX Reference Platform (CY20 onwards).
• May have existing dependencies on boost, tbb or other VFX Reference Platform libs.
• Build and dependency management tooling unknown.

I want

• Precompiled (lib)openassetio (.a/.lib or .so/.dll), and openassetio.hpp (could come from on-site package maintainer)
• If .so/.dll, RUNPATH=$ORIGIN, to harmonise Windows and Linux search paths.
• Documentation of all required shared libraries
• No symbol pollution from internals/statically linked libraries

B: Integration in to C++ Qt desktop application (no Python)

As a

• As [A] but without an integrated Python interpreter that binds application-native SDK objects.

I want

• As [A], but additionally:
• A Python environment, with libpython3.Xm.so (where X is Python version) on the library search path, for loading Python manager plugins (provided by on-site package maintainer)
• A Python bootstrap function to call in a pyopenassetio.hpp, since the app itself doesn't do this.

C: Integration into a non-Qt desktop application

• A python or C++ desktop application that uses some other UI framework.

D: Package maintainer

As a

• conan/vcpkg/conda/etc package maintainer for a company's internal package registry

I want

• A CMake/CPack project.
• Dependency targets parametrised.
• Dependency versions stick to VFX reference platform versions where available
• Documented all dependency versions.
• Documented dependency CMake targets and what they're expected to provide.

E: Standalone Python pipeline script

As a

• Light-weight pipeline script/tool written in pure Python.

I want

• A pip package that installs openassetio (.py/.so/.pyd) for my particular version of Python
• openassetio library statically links all dependencies
• No symbol pollution from internals/statically linked libraries

F: Invocation by another library/framework

• Other frameworks may wish to support the resolution of indirect internal references (eg: Asset Resolver in USD, OpenTimelineIO).

G: Invocation from other languages (eg: JavaScript)

• Extension of tools not traditionally designed around the M&E toolchain, eg: Photoshop's UXP API.

H: Project CI

As a

• GitHub Action

I want

• A yaml file that builds a portable distribution then runs tests, for a matrix of platforms and dependency versions.
• Containerised build environment (VFX reference platform + additional deps).
• Executable C++ and Python tests.

Speculative

1: Managers with SDKs in languages other than C++/Python

• Managers may already be abstracted over some service-based interface, but already have SDKs in other languages.
• Being able to bridge to these would avoid the need to recreate these in C++ or Python.