# http: a non-curl_multi interface? 3 messages from 2009-03-02 to 2009-03-03. Participants: Tay Ray Chuan, Daniel Stenberg. Thread: https://gitlist.dev/t/18090 ## Tay Ray Chuan, 2009-03-02 13:14 Subject: http: a non-curl_multi interface? Message-ID: URL: https://gitlist.dev/e/be6fef0d0903020514h28995ec2v2acd9f65131c1515%40mail.gmail.com ``` 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, 2009-03-02 13:26 Subject: Re: http: a non-curl_multi interface? Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.10.0903021412120.15587%40yvahk2.pbagnpgbe.fr In-Reply-To: ``` 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, 2009-03-03 11:19 Subject: Re: http: a non-curl_multi interface? Message-ID: URL: https://gitlist.dev/e/be6fef0d0903030319k46bd5f9bx69148a920213038d%40mail.gmail.com In-Reply-To: ``` Hi, On Mon, Mar 2, 2009 at 9:26 PM, Daniel Stenberg 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 ```