| Personally, I think it would be worth it for the cross-platform
| ability - keep in mind that the Mozilla source should be pretty portable
| as well, so the only Win32-specific stuff would be discovering the proxy
| settings.
|
| Of course, if you're not going to port across, it may not be worth the
| trouble :)
|
| I think a cross-platform thing along the lines of, say,
| curl_use_browser_proxy(curlHandle) that discovered proxy settings would
| be rather sweet. Although, it would have the potential to balloon out
| into quite a lot of code I guess, and wouldn't be all that precise (if,
| say, the Unix version looked at mozilla, netscape and konqueror
| settings, a w3m user might feel a bit left out - although they could
| always submit a patch :)
|
| It would make it rather easy for anyone to add the ability to discover
| proxies, to their program.

Yep exactly !

But I think that would make curl 2 or 3 times bigger (code size and even
more in memory use) if you just want to be able to interpret the .pac
files... I don't think that's worth. IMHO, libCurl is good because it's
rather small (130 kB DLL).
And the main problem is that it can't be fully automated. Because the user
(and not the coder) has to choose on what browser to get the default
configuration (the one the user uses and know it works). I wanted something
that a user-who-doesn't-know-how-his-computer-works could use without doing
anything (but a browser selection). It's aimed for a silent automatic
product update (checking).

Actually I will do something for that, a set of C++ classes that load the
specified URL correctly. The same C++ interface could be used on other
platforms using different strategies to get the file (libCurl on unices,
wininet on windows, whatever on MacOSX, etc). That's where the portability
could go. Because I think proxy settings are anything but portable (even if
it's very close).
Received on 2001-08-27