> 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'm very sensitive to this need as I too do some embeded applications.
 libproxy is modular and the core is <=35K. You do NOT need to
integrate a full GNOME/Mozilla stack to have basic libproxy support.
Basic libproxy support still provides some nice features though. One
main one includes the ability to lock users to a certain proxy
configuration.

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

This is an interesting solution, though it still has the "broken by
default" property.

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

I agree.

Nathaniel
Received on 2007-12-21