On 7 Jun 2001, Hrvoje Niksic wrote:
[ Disclaimer, please regard this dicussion as what *could* become reality,
if many things would move in the right direction. A dream, a vision,
plain fantasies. ]
(Not related to this, but I thought I could through this in: One of
the blue-sky dreams I have for a rainy day, is converting wget to
use libcurl as transport layer for FTP(S)/HTTP(S)...)
Such a thing is not entirely out of the question. I'm not exactly
satisfied with Wget's backend code and I've been thinking about ways to
redesign it for years now. But designing an HTTP layer is damned hard.
You have to handle the concepts of connection and download, as well
as reconnecting, persistent and non-persistent connections, etc. Then
come the proxies, redirections, protocols based on HTTP which are not
exactly HTTP, and a legion of other nuisances.
Well of course. libcurl is such a library today, and it works. It supports
all these things you mention here above, and more. Multi platform.
I've studied the wget sources before with this purpose in mind, and I realize
it isn't just an afternoon patch we're talking about.
Wget has traditionally been advertised as a no dependency program, i.e.
people have been reported to install it right after `gzip' and `gcc'.
I understand this perfectly.
But if I found a library that handled all of the above issues
*graciously* (sorry folks, not libwww), I think I would prefer to use it
than implement all of those things myself.
It would of course put a great demand on the library in question, and I'm not
saying libcurl of today would fit right into this shoe without any glitch
(I'm not saying it doesn't either, I'm just realistic enough to expect
trouble). The point would instead be that it could be a benefit to work out
the problems, and end up with an even more powerful transport library that
would, well, if not rule the world, at least be a mighty fine library. For
synchronous URL transfers.
I can't but agree about your sentiments for libwww.
I haven't looked at cURL before, but will do so. Is the documentation
available online?
You'll find most libcurl docs from http://curl.haxx.se/libcurl/
If you are willing to advertise its features, take this as an invitation
to do so. :-)
curl is the tool that is powered by libcurl, the client-side URL transfer
library. My focus right now right here is the library parts. libcurl supports
FTP(S), HTTP(S), GOPHER, LDAP, FILE, TELNET, LDAP and DICT. It does both ways
transfers (for FTP and HTTP), persitent connections, cookies, POST, PUT,
rfc1867-posts, kerberos4, authentication and more. Friendly people have
written interfaces for all sorts of languages, including PHP, Perl, Ruby,
Python, Tcl and Java. libcurl never does anything with the actually
transfered data. It transfers, it doesn't interpret nor interfere with the
contents.
I have this comparison table over at the curl site comparing HTTP/FTP tools:
http://curl.haxx.se/docs/comparison-table.html (probable curl bias)
(I'm now reading curl(1) man page and finding many cool things to steal,
interface-wise.)
:-)
Of course (this may be unnecessary to add but I feel I should): I am not the
single person behind curl/libcurl. More than 60 persons are named for having
done non-trivial contributions.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
