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
Received on 2012-09-25 17:33:31 CEST