Currently, when a user downloads a file over HTTP, for example:
$ cernopendata-client download-files --recid 5500
then the downloader uses either "requests" library or "pycurl" library, depending on which one is installed.
The user cannot easily influence choosing one or another if both are installed, such as in the Docker container cernopendata/cernopendata-client:0.2.0. When both are available, "pycurl" is automatically selected by the client package.
This would be OK if both "requests" and "pycurl" downloaders provide the same functionality. However, recently, as part of the work on the resume download functionality #99, one downloader technique offers richer user experience than the other. It would be therefore good to expose the downloader choice up to the user.
Expected behaviour
Let us introduce a new command-line option for the download-files command that would expose the choice of HTTP downloader to use, i.e. "requests" or "pycurl", up to the end user. Example:
However the new --downloader option can come handy for XRootD protocol too, for example when we shall support both "xrootdpyfs" (current) and vanilla "xrootd" (future) downloaders for the XRootD protocol as well.
We can therefore implement the option for the HTTP downloader, keep the XRootD downloader hard-coded to xrootdpyfs, introduce a CLI option validator to make sure only good combinations are accepted, and introduce a test case for it.
Current behaviour
Currently, when a user downloads a file over HTTP, for example:
then the downloader uses either "requests" library or "pycurl" library, depending on which one is installed.
The user cannot easily influence choosing one or another if both are installed, such as in the Docker container
cernopendata/cernopendata-client:0.2.0
. When both are available, "pycurl" is automatically selected by the client package.This would be OK if both "requests" and "pycurl" downloaders provide the same functionality. However, recently, as part of the work on the resume download functionality #99, one downloader technique offers richer user experience than the other. It would be therefore good to expose the downloader choice up to the user.
Expected behaviour
Let us introduce a new command-line option for the
download-files
command that would expose the choice of HTTP downloader to use, i.e. "requests" or "pycurl", up to the end user. Example:Note that some combinations are illegal and will have to be checked for, such as:
However the new
--downloader
option can come handy for XRootD protocol too, for example when we shall support both "xrootdpyfs" (current) and vanilla "xrootd" (future) downloaders for the XRootD protocol as well.We can therefore implement the option for the HTTP downloader, keep the XRootD downloader hard-coded to xrootdpyfs, introduce a CLI option validator to make sure only good combinations are accepted, and introduce a test case for it.