Tech debt: no pattern is used when dealing with cached data in irmaclient.Client

[ivard]

The irmaclient.Client struct currently caches various data, representing the data stored in irmaclient.storage. No specific pattern is followed in this caching process, making it difficult to detect errors in maintaining consistency between the cache and the storage.

Revocation poses a particular challenge because numerous updates are required when re-downloading the nonrevocation witness. These updates occur in background tasks. Currently, it is challenging to assess whether potential race conditions exist because strict module separation or other types of interfacing are not applied.

The cached storage is currently used, among other things, to calculate the choices the user currently has when starting a disclosure session. Presently, an update is sent for each session every time the cache is updated. This mechanism is fragile, and it would be better if each session kept its own administration and only received an event when updates occurred. In this sense, the 'sessions' struct is also considered a code smell.

[sietseringers]

Presently, an update is sent for each session every time the cache is updated.

@ivard, when an issuance session completes then any open disclosure sessions are notified using this line. Is that what you meant with this?

[ivard]

Yes exactly. The issuance session updates both the cache and the files on disk and pokes all other sessions to reload their candidates. If one of these things is forgotten when making a change, really weird stuff can happen.

I think a good approach would be to do some research where in the code the cached client state is used (aka the "Stuff we manage on disk"). A nice goal would be to introduce an interface to separate the storage struct a bit from the rest of the code. If we need the cache functionality for performance reasons, it should be handled on the implementation side of this new interface, such that the rest of the code does not have to be aware of this.