On 25.09.2012 16:37, C. Michael Pilato wrote: > On 09/17/2012 09:34 PM, Bert Huijben wrote: >> On Windows this isn't the normal way to fetch the system wide proxy, nor >> is it on the Mac. Adding environment flags to GUI applications there is >> certainly *not* the right way to look at this problem. The linux specific >> environment variable solution might apply to a linux gui, but not to a >> Windows gui or a Windows/Mac shell or application extension. >> >> My earlier suggestion was to use libproxy, as that handles the normal >> settings on all these platforms. On Linux it appears to use these proxy >> environment variables (and a few others) as that appears to be the common >> way to configure a proxy there, while on the Mac and Windows it properly >> looks at the system proxy settings. It also handles corner cases like the >> support for ignoring proxies for specific hosts. >> >> As libproxy is LGPL I don't think we can add it as an explicit >> dependency, but adding it as an optional dependency would be a proper >> solution. When encapsulated properly we can also add specific >> implementations for other platforms ourselves. (Windows XP and later >> appear to have a standard API that handles all kinds of proxies, >> including pac files which would require some Mozilla components via >> libproxy) > +1 on the optional libproxy dependency. That makes great sense to me. > > However ... since the env-var stuff is *relatively* straightforward, would > we be interested in/willing to *also* implement that (or a subset thereof) > directly in our codebase for non-Windows, non-Mac use only? Or is that just > begging to confuse our users?
If the env-var parsing is implemented in a way that is compatible with libproxy, and it's disabled and completely replaced by libproxy when the latter is enabled/available, then sure, there's no reason not to have both. As long as someone is prepared to maintain both. But if the proxy-detection behaviour changes noticeably when switching from the built-in implementation to what libproxy gives us (always remembering that libproxy will have a superset of the features), then I'd think twice about such a two-pronged approach. -- Brane -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
