>> 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.

> I'm voicing my scepticism, although of course some people would call
me old
> and grumpy... I'm all ears for further input from others on this
topic.

We would always turn this feature off in our application, an embedded
device with limited memory footprint in the consumer space (i.e., no
proxies).

I'd rather see an implementation where the "fall back" (as Alex put it)
invokes a callback to the application, which can then decide how to
proceed with proxy resolution. No current applications break and new
applications can use libproxy or another solution.

Tight integration of libcurl with libproxy, without a simple means of
disabling it through config, would be a mistake, IMO.

Gary Maxwell
Casabi, Inc.
Received on 2007-12-21