Persistent cache mechanism

[foundrytom]

Capturing discussion:

• Add a CacheInterfacePtr (cache?) to ManagerStateBase that is set by the interface implementation in createState and/or createChildState (a member var over a method to avoid a Manager.cpp method going into python when there is no C++ manager interface implementation)
• Managers can then use the interface to the cache to pre-populate results, or serialize etc. to a path, and encode in persistenceTokenForState, so the cache could be re-populated and set back in stateFromPersistenceToken.
• Manager.cpp, will attempt to lookup an API call in the cache if there is one in the context
• A massive win is if the cache can be used by the middleware to bypass a python manager plugin
• Assuming all traitsdata traits + properties of the context would invalidate the cache is probably pessimistic. Could have a runtime-constant set of traits that bust the cache as a ManagerInterface method? eg USD's varies with context mechanism.

[foundrytom]

Ask people for input - broad assumption is that the distributed serialized on disk cache is a read-only cache to prevent the explosion that is networked concurrent writes to the same cache.

Consider all possible cache implementations (eg Redis, memcached) when deciding what goes into the cache interface.

[foundrytom]

The manager is general in charge of which cache is used as it knows about the pipeline (or exposes that configuration)

[foundrytom]

Consider making this in the same ilk as the GRPC prototype, so its just another wrapper ManagerInterface + factory so the core API doesn't know about it.

[elliotcmorris]

We could consider this an "TraitsDataCache", where the key is just entityRef + context, and if the traitsdata contains the traits in question, it's a hit, otherwise a miss.

[elliotcmorris]

We may need tests for distributed generation in the publishing workflow for this, since the context would be distributed and intermediate write access resolves will interact with the cache.

[elliotcmorris]

It's painful, but categorising this as non essential as we could release without it, and it's a big thing. This dosen't mean it's not still on the 1.0.0 roadmap.