On 09/25/2012 11:32 AM, Branko Čibej wrote:
> 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.
We have an open issue (#3740) about teaching Subversion to make use of
neon's libproxy integration, implying that currently it doesn't.
As an aside, a bit ago I filed a new issue for libproxy support in
Subversion (#4240), and made four other existing issues depend on it.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-10-03 20:51:31 CEST