Identify necessary breaking changes for UI Delegation

[SamCrooksFoundry]

What

This is a spike to identify any breaking changes required in the OpenAssetIO library to facilitate UI Delegation.

Why

To add placeholders so that development can proceed over the next year without breaking existing integrations.

Acceptance Criteria

A rough outline of how UI delegation will work.

An outline of what changes need to be made to the API to support UI delegation, especially breaking changes.

[feltech]

Added the following PRs related to this:

• DR for UI delegation plugin architecture #1382
• Add UI delegation notebook OpenAssetIO-MediaCreation#100

[feltech]

Based on feedback on the aforementioned PRs, especially the decision record, it seems fairly clear that breaking changes will not be needed.

The DR concludes that the UI delegation plugin system can be entirely distinct from the main manager plugin system.

The primary reason for breaking changes would then be in changing the public API to give explicit access to the private implementation of the manager plugin from the UI delegate plugin.

However, this is unlikely to be necessary. If only public (i.e. Manager) access is needed, then no API changes are necessary. Otherwise, the ideal solution is for plugin authors to make use of the Context.managerState mechanism, which again means no public API changes.

If we want to add to the API to provide the UI delegate plugin with access to the underlying ManagerInterface implementation of the manager plugin, then the obvious solution is to provide a new method on the public Manager middleware class, which returns a reference to the associated ManagerInterface. Providing an (accessor to a pre-existing member wouldn't change the binary layout of anything, and it wouldn't involve any virtual methods. So from a C++ ABI perspective it would be a patch-level update (in semver speak), along with the rest of the UI delegation functionality (in theory).

So I think it's safe to close this issue, based on current information.