On 25.09.2012 17:10, Stefan Sperling wrote: > On Tue, Sep 25, 2012 at 11:01:44AM -0400, C. Michael Pilato wrote: >> On 09/25/2012 10:42 AM, Branko Čibej wrote: >>> On 25.09.2012 16:37, C. Michael Pilato wrote: >>>> +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. >> Yes, I concur on all points. > This may be a stupid question since I'm jumping half-way into this > thread and haven't read all of it, but: > > AFAIK neon optionally links to libproxy. > So why doesn't neon figure out proxy stuff for us in a transparent > manner? Is there some reason that prevents this from working or is > it impractical in the first place? > > And if neon has support for this, then why doesn't serf have similar > support? I thought serf was supposed to be on par with neon in terms > of features before we made it the default.
"In terms of features we use." I don't know that anyone ever tried to use neon with libproxy in Subversion. But, indeed, it would be nice if proxy handling were part of the HTTP layer library. -- Brane -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
