http: a non-curl_multi interface?

http: a non-curl_multi interface?

[Tay Ray Chuan]

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

Re: http: a non-curl_multi interface?

[Daniel Stenberg]

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

Re: http: a non-curl_multi interface?

[Tay Ray Chuan]

Hi,

On Mon, Mar 2, 2009 at 9:26 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> 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