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.
Received on 2012-09-25 17:10:45 CEST