{"thread":{"id":"18090","subject":"http: a non-curl_multi interface?","startedAt":"2009-03-02T13:14:35Z","lastAt":"2009-03-03T11:19:33Z","messageCount":3,"participants":["Tay Ray Chuan","Daniel Stenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106701","messageId":"be6fef0d0903020514h28995ec2v2acd9f65131c1515@mail.gmail.com","threadId":"18090","inReplyTo":null,"subject":"http: a non-curl_multi interface?","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2009-03-02T13:14:35Z","receivedAt":"2009-03-02T13:14:35Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"HI,\n\nthere's been several complaints about how git uses curl, particularly\nhow it forces one to use curl's multi interface, so I've tried my hand\nat implementing a curl interface that doesn't need curl_multi.\n\nThis would allow git to work without curl_multi.\n\nThe non-curl_multi set of functions are done, and I've also taught\npush and http-push --persistent, to force git to behave as though\nUSE_CURL_MULTI isn't defined.\n\nDo you guys think this would bring any benefits, apart from requiring\nthe user to use a curl library with the multi interface? Based on what\nI read in the docs, this would mean less open/closed connections,\nminimized credential prompting (if authentication is required), more\nbackward compatibility, but it would also mean a possible performance\ndegradation in git, since all http requests are sequential.\n\n--\nCheers,\nRay Chuan\n"},{"id":"106702","messageId":"alpine.DEB.1.10.0903021412120.15587@yvahk2.pbagnpgbe.fr","threadId":"18090","inReplyTo":"be6fef0d0903020514h28995ec2v2acd9f65131c1515@mail.gmail.com","subject":"Re: http: a non-curl_multi interface?","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2009-03-02T13:26:47Z","receivedAt":"2009-03-02T13:26:47Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Mon, 2 Mar 2009, Tay Ray Chuan wrote:\n\nI'm replying on this topic as a libcurl guy, I don't know much of git \ninternals.\n\n> Do you guys think this would bring any benefits, apart from requiring\n> the user to use a curl library with the multi interface?\n\nYou mean NOT requiring then I guess.\n\nWhat I don't quite grasp (and I must admit I have not followed the critique on \nthis matter) is why using the multi interface of libcurl is a problem to \nanyone as all libcurl versions in modern times features it. And if you have a \nlibcurl with it working badly, you have a too old libcurl anyway and should \nrather upgrade...\n\n> Based on what I read in the docs, this would mean less open/closed \n> connections,\n\nI don't see how that is true. In fact, properly used I would claim that an \napplication using the multi interface would in general use less connections \nand do more connection re-use than otherwise. But of course it depends on a \nlot of factors.\n\nAgain, this requires a reasonably recent libcurl (since 7.16.0 - october 2006 \n- libcurl keeps the \"connection cache\" in the multi handle instead of in each \nindividual easy handle.)\n\n> minimized credential prompting (if authentication is required), more \n> backward compatibility, but it would also mean a possible performance \n> degradation in git, since all http requests are sequential.\n\nI figure you can test that fairly easy now when you have a patch pending for \nthis change and the existing code base is using the multi interface \napproach...\n\n-- \n\n  / daniel.haxx.se\n"},{"id":"106816","messageId":"be6fef0d0903030319k46bd5f9bx69148a920213038d@mail.gmail.com","threadId":"18090","inReplyTo":"alpine.DEB.1.10.0903021412120.15587@yvahk2.pbagnpgbe.fr","subject":"Re: http: a non-curl_multi interface?","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2009-03-03T11:19:33Z","receivedAt":"2009-03-03T11:19:33Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Mon, Mar 2, 2009 at 9:26 PM, Daniel Stenberg <daniel@haxx.se> wrote:\n> What I don't quite grasp (and I must admit I have not followed the critique\n> on this matter) is why using the multi interface of libcurl is a problem to\n> anyone as all libcurl versions in modern times features it. And if you have\n> a libcurl with it working badly, you have a too old libcurl anyway and\n> should rather upgrade...\n>\n> ...\n>\n> I don't see how that is true. In fact, properly used I would claim that an\n> application using the multi interface would in general use less connections\n> and do more connection re-use than otherwise. But of course it depends on a\n> lot of factors.\n\nHmm, there aren't any very obvious benefits are there?\n\nIn that case, I guess, an re-organization of the http api/curl usage\nwould be more useful to git.\n\n-- \nCheers,\nRay Chuan\n"}]}