bkw777
commented
1 year ago This is not as simple as the sudo or xterm options. The download command isn't simply run, it's highly integrated.
The .deb files are downloaded in batch by writing a special aria2c syntax job file format to stdin, and parsing the stdout to monitor progress while working.
To support a different downloader, you would need to write a whole different "driver" for that downloader, essentially a replacement DownloadManager.vala (also other parts would need to be decoupled a little to make it so all the special bits are inside DownloadManager, to allow drop-in replacement of some other DownloadManager, but that's not a problem)
Never the less I've always wanted this to be configurable too.
I think I should do 2 things. 1 - Make AsyncTask more generic and clean up the seperation so that everything special to aria2c is all just inside DownloadManager, and then it would be possible to have other versions of DownloadManager that drop in without having to change anything else. I've been planning to do that to make a version that uses libcurl instead of an external executable.
2 - That would be nice just on principle but in addition to that it would be useful to have an option like the xterm option where there is both internal and external options, where even if the internal option is all integrated, the external options are simpler where they DO just run the command with only a simple string substitution for the url and filename etc. This method of operating would be less efficient since it would have to run the command once per individual file, and it's a lot of files. But that's ok as long as the good reference method is still always available built-in.
There is still a bit of a problem with special settings like proxy. Each different downloader would have it's own different way of doing that. I guess that will have to be handled by supplying more special tokens similar to printf format specifiers, like instead of %s for string, maybe %u for url and %p for proxy, etc, or maybe do them as environment variables like ${URL} , ${PROXY}, etc.
Hm, I guess we could even still support batch mode by having a variable for a url list. At run-time, we decide whether to run a loop if single-file downloads or a single batch download by just looking at the configured command to see which it has ${URL} or ${URLLIST} in it.
The checksums would be a little more work. Righ now it hands the checksums to aria2c, and aria2c is what checks the checksums. With any other command, we'd have to do our own checksum verification.
Similarly we'd have to provide progress monitoring by repeatedly statting the partial download file instead of reading the progress from the command output, or we just accept the progress being messier by just dumping the commands progress output to stdout instead of generating our own progress bar.
I guess I've just convinced myself it's doable.
[Feature Request]: Select external downloader (aria2 and e.t.c)