Entity change tracking

What

As a host, I'd like to be able to determine when an entity has changed to avoid redundant API calls.

Why

In order to do do some work (such as render a composition that loads hundreds of images), I need to resolve assorted information about the entities that represent the pre-requisite inputs to the task (such as path, frame range, etc). If I am working in a persistent interactive session (as opposed to a one-off process), this data may change during the lifetime of the session. I need to make sure that the user is aware of any changes that may be relevant.

At present, the guidelines are to re-resolve as frequently as possible without degrading performance, however even this has a significant overhead in many cases (such as node graph change tracking). As such, a host is forced into some kind of local caching regardless, as true JIT resolution is too expensive.

Notes

The current guidance is in place for several reasons:

• Consultation with manager authors suggested an initial strategy of "make the API as thin as possible, so we can control this mechanism" was prudent as whatever API-level caching strategy we pick may not be well suited to any given back-end implementation.
• The assumption that we could make the API light weight enough (when the C++ only path was used) that the call into the manager-side cache was reasonable.

This has several practical issues:

• It places a significant burden on the manager code to ensure performance, which in itself is a non-trivial programming exercise.
• Managers written in Python etc... will be unable to implement a suitably thin bridge to a cache of their own due to the GIL.
• Even with the thinest API, no work is better than some work.

The result of which is that hosts are generally forced to introduce a caching layer of their own in between resolution and use of the resulting data (often in a similar fashion to their existing file handling code).

• As soon as any host-side caching is in play, the possibility for incorrect data re-surfaces.
• It places significant burden on the hosts implementation to maintain performance.

Consequently, we accept the need for host-side caching as a reality in any production-ready deployment that has to support a range of managers. How do we make this as simple as possible for everyone?

There have been a few discussions on this matter that have presented potential approaches. These need proper consideration with representatives from both the manager and host communities:

• A CacheControl trait that can be resolved with entity data, similar in behaviour to the cache-control HTTP header.
• A first-class pub/sub mechanism where hosts can subscribe to push updates for specific entities/traits.

The solution to this problem needs to be considerate of the variety of back-end implementations on both sides to ensure its presence doesn't significantly affect the ability of a manager or a host to support the API. We should consider what 'out the box' mechanisms the API could provide to alleviate the burden on both parties (such as robust read-through caching, hooked up to available change tracking mechanisms etc).

No files, tests, or entry points are identified. Start by reviewing the existing entity-resolution guidance and the proposed CacheControl and pub/sub approaches, then consult the manager and host requirements described here. Done requires an agreed, implementable change-tracking design that addresses caching and backend variety.