...
The function and design principles of the client-side file cache need to be made explicit. The options are below.
...
Common Principles:
...
These principles are common to all approaches
The client has a file cache on the local file system. When an File or Record entity is fetched, if its associated files are fetched then they go into the cache.
The files in the cache may be modified. That is, the client may not assume that a file in the cache is identical to the one in Synapse.
Option 1: Local modifications are stored in client memory
There is no requirement that the local file associated with an entity be in the cache. That is, the entity must hold a reference to the local file handle, without assuming its location.
Files may be deleted from the cache by the client at any time.TODO: How do we support caching in between sessions? Is it a valid use case to use the cache as a mirror, or is that a misuse of its function?
Option 2:
...
Local modifications are stored in file system
When an entity is stored, any associated files are moved into the cache immediately.
The location of a cached file can always be derived from entity meta data. E.g. the entity id and file name may be used to construct the location file handle.
The cache may not be modified by the client except in the course of doing entity CRUD in Synapse. In particular, the cache is not a 'scratch' space. (Is this requirement really needed?)