Caching POA

[dkulic]

Signed-off-by: Darko Kulic darko.kulic@evernym.com

[vimmerru]

1. I suggest to remove submitter_did param as it can be hard-coded or auto-generated for each request
2. Do we need to return cache timestamp also?
3. I suggest to add options_json that will allow to:

• Skip caching
• Provide required freshness

[dkulic]

3. Skip caching have sense in a meaning do not store retrieved value inside of cache.
   For freshness, I think that schema and credential_def cannot be updated (without change of id) so freshness is not needed. For that reason I do not see need for cache timestamp.

[vimmerru]

In my understanding CredDef and Schema can be updated. Schema can get backward compatible changes. Keys in CredDef can be rotated in some cases. Also some entities we plan to cache like DID Doc can be updated much often. @ashcherbakov What do you think?

[vimmerru]

I believe we need to decide what exact option to use or provide an API for configuration of cache. For example, we can add behavior configuration to indy_init() method.

[vimmerru]

To define purge behavior i also suggest to look to http cache options:

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache 
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

In this case we can define exact behavior for each entity.

[vimmerru]

@dkulic @jovfer @ashcherbakov @dhh1128 What do you think on ^?

[dkulic]

I am not sure I follow your thoughts regarding defining exact behavior for each entity. Do you mean adding specific caching policy to each entity, so that purging process may selectively purge only entities which satisfy its own policy? If this is the case, that seams to complicated...

[vimmerru]

@dkulic The idea is very simple:

1. When app asks for some entity it can explicitly say how long it want to store this entity in cache
2. On start app can call purge method that will remove all outdated records.

[dkulic]

That sounds doable. :)

[vimmerru]

also purge can have force param that will remove all cache records.

[dkulic]

I like the timeout idea, because you may lock in some cache items in cache forever. (eg. so you may use your passport on foreign airport, without internet).

[dkulic]

After some thoughts I figured out I do not like idea about purging on start/specifying ttl for every entity. I would expect that normally you would want data to be in cache for longer time, so you may during request choose max-age of data you want. I would modify it like this:

1. When requesting a data, app may use some cache control options (like max-age, no-cache, no-store, only-if-cached, for eg.)
2. purge method would have option of specifying max-age (or similar), so older data would be deleted.

[vimmerru]

I believe we can use something similar to http-cache control headers:

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache 
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

[dkulic]

Some of these options look very useful. I would like not to have too many options, which may be too confusing. I especially like: max-age, only-if-cached.

[jovfer]

@dkulic @vimmerru what is the next step for this PoA?

[jovfer]

I like the latest changes around cache lifetime. I'm voting to merge this design, implement it in code but mark experimental for the next one release