Networking Library for Gpredict

I have spent quite some time lately in trying to figure out how I should implement the automatic TLE update in Gpredict. The idea is that Gpredict should be able to fetch fresh TLE data from the internet, via HTTP or FTP, and update the contents of the local file.

The key issue here is what to use for networking library? By networking library I do not only mean TCP/IP library, but something that speaks HTTP and prefereably FTP, too. Moreover, it has to be available for Linux/Win/Mac, otherwise I would diverge from the current availability philosophy of gpredict.

The first idea I investigated was the HTTP code from Gaim. Gaim has a function for checking the availability of new version, and this seems to be done by reading a file from the Gaim website. The code supports proxies, and is portable, but it is rather integrated into Gaim.

The other possibility under investigation was wget. This is a very complete command line tool, and it is available for both Unix, Windows and Mac. Relying on external wget on Linux, and including wget.exe in the win32 distribution would be a pretty safe solution, although not perfect.

Then, while I was googling for wget and reading several posting concerning its availability for various platforms, I came across cURL and libcurl: A command line tool with corresponding library for transferring files with URL syntax, supporting FTP, FTPS, TFTP, HTTP, HTTPS, TELNET, DICT, FILE and LDAP. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, kerberos…), file transfer resume, proxy tunneling and a busload of other useful tricks. It is available for all known and unknown platforms, inlcuding Unix, Win, and Mac – just have a look at the download page. It looks perfect!

I didn’t have time to read through all the documentation, but it seems to me that by using libcurl, which is included in most linux distros (?), I can focus on the functional aspects of the TLE update and do a top-down design, rather than having to keep in mind what is possible and what is not at the protocol level. I am very excited about this new finding.