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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
