Background
The file-service has been planned to save and serve files on/from persistent storage. Besides the exact hosting capabilities and configuration, that do not affect the implementation of the service, we need to clarify what's the domain of the service, where's the domain boundary (that separates the services from other services) and what's the desired functionality.
Klaas proposed that the service should able to serve files based on a URL. Other services save files in a directory, that the files-service can access to serve files.
Pro: file-service is already implemented
Contra: different services need methods to read/save files, what’s about naming collisions if different services can write into one directory, no exact domain boundaries of the services (as more than one service is able to alter the managed data and structures)
Roy proposed that the file-service is used to save and serve files by it’s API. So it would be similar to ftp or a MediaDB that is used by all the other services.
Pro: exact domain boundaries of services (one service is responsible for files), no conflicts due to shared directory structure (e.g. write conflicts), no need to implement some methods in more than one service (e.g. save/read files).
Contra: not implemented yet
Are there any side effects for each of the proposed alternatives? What’s less work (not just for september, but also for the time after september)?