7 - (rt) propose an interface for threaded batch downloads
8 - (mds) design a new progress-meter interface for threaded
10 - (rt) look at CacheFTPHandler and its implications for batch mode
13 * progress meter stuff
14 - support for retrying a file (in a MirrorGroup, for example)
15 - failure support (done?)
16 - support for when we have less information (no sizes, etc)
17 - check compatibility with gui interfaces
18 - starting a download with some parts already read (with reget,
21 * look at making the 'check_timestamp' reget mode work with ftp.
22 Currently, we NEVER get a timestamp back, so we can't compare.
23 We'll probably need to subclass/replace either the urllib2 FTP handler
24 or the ftplib FTP object (or both, but I doubt it). It may or may not
25 be worth it just for this one mode of reget. It fails safely - by
26 getting the entire file.
28 * cache dns lookups -- for a possible approach, see
29 https://lists.dulug.duke.edu/pipermail/yum-devel/2004-March/000136.html
33 * BatchURLGrabber/BatchMirrorGroup for concurrent downloads and possibly to
34 handle forking into secure/setuid sandbox.
36 * Consider adding a progress_meter implementation that can be used in
37 concurrent download situations (I have some ideas about this -mds)
39 * Consider using CacheFTPHandler instead of FTPHandler in byterange.py.
40 CacheFTPHandler reuses connections but this may lead to problems with
41 ranges. I've tested CacheFTPHandler with ranges using vsftpd as a
42 server and everything works fine but this needs more exhaustive tests
43 or a fallback mechanism. Also, CacheFTPHandler breaks with multiple
46 * Consider some statistics tracking so that urlgrabber can record the
47 speed/reliability of different servers. This could then be used by
48 the mirror code for choosing optimal servers (slick, eh?)
50 * check SSL certs. This may require PyOpenSSL.