General cache / state persistence mechanism?

[cmgrote]

In implementing some of the repository connectors, it has become clear that it could be useful to have a standard means through which to persist state -- outside the underlying metadata repository of the connector itself.

(For example, for IGC: odpi/egeria-connector-ibm-information-server#14)

Given that other repository connectors and indeed other servers or governance daemons (for example, the DataStage proxy) could also potentially be improved by having such a persistence mechanism, it seems like it might be a good idea to provide some generic capability for such a configurable (non-)persistent cache mechanism as part of the core of Egeria itself? Each instance of it could then be configured independently by connectors, proxies, daemons, etc for their use with whatever characteristics they require (persistent vs non-persistent, etc) and potentially different back-ends (eg. Redis, H2, etc).

If we agree this does make sense, presumably the steps would be:

1. Define the interface we would want to generically expose to configure and CRUD against such a "cache"
2. Implement one or more example back-ends (presumably going through OCF?)

[cmgrote]

Moved out to 1.4. Probably not even on the critical path for that release, if we have an InTopic to write into for the DE OMAS as part of 1.4...

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[cmgrote]

I'll close this for now, as I don't think there is any urgent need driving it anymore (no more need for state persistence in the connectors use case listed originally). If we find another use case, we can re-open.