In the current implementation, result files are referenced by their paths rather than by random identifiers or, ideally, ids given in the service configuration file. The current approach is dictated by the file hosting issue #41 as for the proxy server to be able to find the file, its id must be the same as its path. This might cause potential problems with the REST API when file path is mixed with path parameters. Additionally, using predictable file ids such as <job_id>/<result_id>_<hash> would significantly help with automated job chaining. Managing files by slivka application and using X-Sendfile headers would be helpful, but break the compatibility with many proxy servers that does not support this header.
warownia1
commented
11 months ago
In the current implementation, result files are referenced by their paths rather than by random identifiers or, ideally, ids given in the service configuration file. The current approach is dictated by the file hosting issue #41 as for the proxy server to be able to find the file, its id must be the same as its path. This might cause potential problems with the REST API when file path is mixed with path parameters. Additionally, using predictable file ids such as
<job_id>/<result_id>_<hash>would significantly help with automated job chaining. Managing files by slivka application and usingX-Sendfileheaders would be helpful, but break the compatibility with many proxy servers that does not support this header.