> I'm sure there are lots of applications that will have great use of this, but
> I disagree with the conclusion that libcurl should integrade this library. In
> my view, applications are just as well off by using libproxy to extract the
> proxy information and then set that to libcurl with the proper option(s).

Currently, libcurl can use proxies that are manually passed into
libcurl via the api. This should not change. However, if no option is
passed, libcurl falls back to detecting the environment variable.
Instead of this behavior, fall back onto libproxy. libproxy can use
environment variables, so no compatibility is lost. However, you gain
the ability to read configuration from GNOME or KDE (Mac & Windows
soon to come) and to perform autodetection and adjust to changing
network topology.

We will suggest adoption from individual applications as well, but
consider that if you link to libproxy, all the applications that use
libcurl will be saved the effort of having to link to it themselves.
It seems more reasonable to make such a change at the root of the
dependency tree, rather than along the branches. Aside from a couple
of hours of coding there is nothing to lose and a lot to gain.

Alex
Received on 2007-12-20