USD Ar 2 MVP workflow - Githubissues

foundrytom commented 1 year ago

Business Requirements

We need to demonstrate OpenAssetIO reduces the integrating cost compared to existing multi-tool workflows with direct integrations that require parallel implementations using native APIs
We need to provide a solution for coherent asset resolution in DCCs that consume data from a USD stage as well as their own documents
USD is rising in popularity in the industry and we need to demonstrate that OpenAssetIO is not in competition with AR2, is compatible with its workflows to demonstrate the flexibility of OpenAssetIO's API design.
The work delivered in the sprint can be parked in a functional state usable by the community so the team can work on other things. A source-only mechanism for distribution is fine.
It is ok (though undesirable) for the implementation to be non optimal if it aids completion of sample workflows.
Implementation is of a suitable quality that works as described when tested by third parties.

User Requirements

USD authors

As a user I can include OpenAssetIO entity references in USDs resolvable composition arcs, using Python manager plugins.
References should be in the same form as they would be used in other situations where OpenAssetIO is used to resolve data assuming USDs native syntax (@<ref>@<rootPrim>). eg: @ftrack://some/entity@ instead of @openassetio://ftrack???some...@
OpenAssetIO resolved locatableContent trait data is assumed to be an absolute file URL.
Non-entity reference strings are handled by the ArDefaultResolver.
The plugin should use standard USD mechanisms for installation.
The plugin should use my default OpenAssetIO configuration.

Manager authors

The resolver plugin follows OpenAssetIO calling conventions including opt-out and other safe guards.

Software Requirements

Functional

The OpenAssetIO resolver plugin for AR2 does not declare that it uses a context.
An ArDefaultResolver instance is used to provide "default USD behaviour" for strings that aren't entity refrences.
The plugin obeys OpenAssetIO API contracts for Manager/Host interactions for required call sequencing.
The plugin obeys OpenAssetIO API contracts for Manager/Host interactions for opt-in/out behaviour adaption.
The plugin always reports an invalid ArTimestamp for queries regarding modification time, indicating OpenAssetIO assets are immutable.
The plugin makes no additional queries to populate GetAssetInfo calls.
The plugin errors for unsupported asset-centric functionality:
- Write workflows (fatal).
The plugins passes through in CreateIdentifier, ignoring anchor path, if the reference is an entity reference. (will add getRelatedReferences later)
If a non-assetized asset path is anchored to an assetized anchorPath, the anchorPath is resolved to it's locatableContent trait so that standard ArDefaultResolver behaviour is applied to the non-assetized input.

Non-functional

Community members have instructions on how to obtain, build and run the plugin from source them selves.
The plugin can be used on CY2022 Linux.
The plugin makes optimal use of API methods where possible to avoid redundant overhead.

Tasks

[x] #11

elliotcmorris commented 1 year ago

Read workflow

Notes on tactical plan, to be issue-tized if necessary.

Individual tasks.

Desrisking/Investigating CreateIdentifier/Resolve strategy. There were questions on this. Whilst we feel this is a solvable problem, specific implementational requirements remain rather vague. If this investigation becomes too complex or time-consuming, it is acceptable to move forward having certain combinations of assetized/non-assetized inputs between the assetPath and the anchorAssetPath be unsupported and throw errors.
Integration test coverage Produce a high level set of integration tests that load USD documents and assert values from them, capturing the user requirements. Produce accompanying data for these tests. Probably end up with 5-8 tests.
Integrate OpenAssetIO Integrate OpenAssetIO with the resolver plugin. This likely means having to build OpenAssetIO manually, and integrating that with CI. Initialise the python plug-in system in the constructor. Configure OpenAssetIO with a manager (BAL almost certainly) For the moment, a requirement for this resolver is that your enclosing application be being run from a python environment, as there is no C++ manager to facilitate otherwise.
Method implementation Implement specific resolver functionality. The implementation of methods can be parallelized as necessary. All other methods should be left unimplemented so the default implementation is used.

RAFTD = Resolve and Forward To Default.

CreateIdentifier
CreateIdentifierForNewAsset (same as CreateIdentifier)
Resolve (if isEntityReference {Identity function}, else RAFTD)
ResolveForNewAsset (same as resolve)
GetExtension (RAFTD)
OpenAsset (RAFTD)
OpenAssetForWrite (return invalid)

In all cases where we resolve and forward to default, we will need to check if the string is an entity reference, and if not, then we just forward to defaultResolver without resolving.

Unmanaged traits, ManagerPolicy. Ensure unmanaged locatableContent trait queries are always passed through to the default resolver, and that we're not calling resolve on them. Devise an efficient way to test this.