threads / discuss / 18090

http: a non-curl_multi interface?

Subject: http: a non-curl_multi interface?

## tl;dr

3 messages between Mar 2, 2009 and Mar 3, 2009.

replies: 2people: 2as markdown or json

Tay Ray Chuan· Mar 2, 2009, 13:14 UTC · lore

HI,

there's been several complaints about how git uses curl, particularly how it forces one to use curl's multi interface, so I've tried my hand at implementing a curl interface that doesn't need curl_multi.

This would allow git to work without curl_multi.

The non-curl_multi set of functions are done, and I've also taught push and http-push --persistent, to force git to behave as though USE_CURL_MULTI isn't defined.

Do you guys think this would bring any benefits, apart from requiring the user to use a curl library with the multi interface? Based on what I read in the docs, this would mean less open/closed connections, 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.

-- Cheers, Ray Chuan

Daniel Stenberg· Mar 2, 2009, 13:26 UTC · re: Tay Ray Chuan · lore

Re: http: a non-curl_multi interface?

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

Tay Ray Chuan· Mar 3, 2009, 11:19 UTC · re: Daniel Stenberg · lore

Re: http: a non-curl_multi interface?

Hi,

On Mon, Mar 2, 2009 at 9:26 PM, Daniel Stenberg <daniel@haxx.se> wrote:

Show 12 quoted lines

> 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...
>
> ...
>
> 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.

Hmm, there aren't any very obvious benefits are there?

In that case, I guess, an re-organization of the http api/curl usage would be more useful to git.

-- 
Cheers,
Ray Chuan