On Thu, 20 Dec 2007, Nathaniel McCallum wrote:

>> Although, making a JavaScript interpreter a prerequisite turns curl into a
>> pretty heavy-weight app.
>
> This is not how libproxy works. libproxy has no dependencies of its own.
> Currently its size is 35K, but we are looking to shrink it, not grow it. All
> functionality is added via plugins at runtime.

Well run-time or not doesn't really matter IMHO, it's just a question of which
loader that loads the code. If you want a somewhat complete proxy-detection
you _need_ to handle PAC and to handle PAC you need a javascript interpreter
and more, and that is a significant amount of code.

And with PAC you also add HTTP round-trips, DNS lookups and more for each use.

I also want to stress that libcurl by design has no data that survives between
different handles[*] so if libcurl would use libproxy to scan/detect for what
proxy to use, it MUST do it again every time a new handle is created and used.
And for the PAC case, you need to push the URL trough a javascript engine to
get a proxy out and that just can't be a swift operation...

An application however, can keep that info around for its entire life time and
it would know much better if and when to detect proxies automatically etc.

curl (the command line tool) is such an application and I'd like to see it
start using libproxy with an option to enable it.

> So for instance, if you would like to do WPAD/PAC, you'll need to install a
> plugin that provides a javascript interpreter (currently mozjs; webkit, etc
> soon to come). So for the basic use case "have basic proxy configuration",
> libproxy fits the bill. For the case of "I want it to use GNOME/KDE and
> Mozilla", libproxy fits the bill.

Sure, but when you bring in libproxy as the new golden way of detecting proxy,
I think just extracting it from GNOME, KDE and Mozilla as long as it isn't
PAC, is rather half-baked IMHO.

In fact, I've personally never felt a need for GNOME, KDE or Mozilla
auto-detection but I've felt the need for PAC parsing...

(BTW, totally unrelated but there seems to be several other projects and libs
called libproxy already, perhaps you should using an alternative name that
makes your project stand out?)

[*] = there are some anyways, but they are in third party libraries basically
and we want to avoid that at all costs to remain re-entrant and thread-safe.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html