...
The function and design principles of the client-side file cache need to be made explicit. The options are below.
...
:
...
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 When a file is added to an entity and pushed to Synapse, the local copy does not move. Thus there is no guarantee that the local file associated with an entity be in the download cache. That is, the (The entity must hold keep a reference to the local file handle, without assuming its location.
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 arguments for this principle are: Moving large files could be expensive with wasteful duplication; the file might be a script that the user is editing.)
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, even if the entity's e-tag has not changed. (TODO: How DOES the client know a file has been modified? One way is to keep a copy of the md5 in memory upon synGet or synStore, and compare when storing again.)