Re: http: a non-curl_multi interface?

From: Daniel Stenberg <daniel@haxx.se>
Date: Mar 2, 2009, 13:26 UTC
Message-ID: <alpine.DEB.1.10.0903021412120.15587@yvahk2.pbagnpgbe.fr>
In-Reply-To: <be6fef0d0903020514h28995ec2v2acd9f65131c1515@mail.gmail.com>

On Mon, 2 Mar 2009, Tay Ray Chuan wrote:

I'm replying on this topic as a libcurl guy, I don't know much of git internals.

> Do you guys think this would bring any benefits, apart from requiring
> the user to use a curl library with the multi interface?

You mean NOT requiring then I guess.

What I don't quite grasp (and I must admit I have not followed the critique on this matter) is why using the multi interface of libcurl is a problem to anyone as all libcurl versions in modern times features it. And if you have a libcurl with it working badly, you have a too old libcurl anyway and should rather upgrade...

> Based on what I read in the docs, this would mean less open/closed 
> connections,

I don't see how that is true. In fact, properly used I would claim that an application using the multi interface would in general use less connections and do more connection re-use than otherwise. But of course it depends on a lot of factors.

Again, this requires a reasonably recent libcurl (since 7.16.0 - october 2006 
- libcurl keeps the "connection cache" in the multi handle instead of in each 
individual easy handle.)

> minimized credential prompting (if authentication is required), more 
> backward compatibility, but it would also mean a possible performance 
> degradation in git, since all http requests are sequential.

I figure you can test that fairly easy now when you have a patch pending for this change and the existing code base is using the multi interface approach...

-- 
  / daniel.haxx.se