{"thread":{"id":"26366","subject":"Status of dumb http transport?","startedAt":"2011-01-30T15:07:52Z","lastAt":"2011-01-30T16:01:36Z","messageCount":2,"participants":["Martin Langhoff","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160050","messageId":"AANLkTik99NNjNwLbj3-xEvVqiYUENiaREYAeJUC0bwVY@mail.gmail.com","threadId":"26366","inReplyTo":null,"subject":"Status of dumb http transport?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2011-01-30T15:07:52Z","receivedAt":"2011-01-30T15:07:52Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Hi List!\n\nWhat is the state of dumb http transport today, for fetching updates?\nIs the client code smart enough to fetch indexes and use range\nrequests? If so, how does that fare for latency?\n\nBackground: I am looking at whether yum repositories' data (currently\nin sqlite & xml) could benefit from being a git (or very gittish)\ndatabase -- with a bit of re-organizing to make it git-efficient of\ncourse.\n\nNot the data that would benefit, but rather, users pulling updates\nfrom fast-moving repos (updates, updates-testing, rawhide...).\n\nOne of the constraints is that this has to be http, and work well\nacross a universe of mirrors (that won't install or configure\nsoftware) and the good bad and ugly world of http proxies. Yum can be\ntaught to use the git proto, but that won't gain widespread use\nquickly -- http is and will be the mainstay for a long time.\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- Software Architect - OLPC\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"160051","messageId":"m3pqre9y9y.fsf@localhost.localdomain","threadId":"26366","inReplyTo":"AANLkTik99NNjNwLbj3-xEvVqiYUENiaREYAeJUC0bwVY@mail.gmail.com","subject":"Re: Status of dumb http transport?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-01-30T16:01:36Z","receivedAt":"2011-01-30T16:01:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> What is the state of dumb http transport today, for fetching updates?\n> Is the client code smart enough to fetch indexes and use range\n> requests? If so, how does that fare for latency?\n\nA good description of \"dumb\" http transport can be found in Pro Git\nbook, in chapter 9.6 \"Transfer Protocols\", section \"The Dumb Protocol\"\nhttp://progit.org/book/ch9-6.html\n \nIn short \"dumb\" http transport is realy dumb, it consults\n.git/info/refs to know where to start from, and\n.git/objects/info/packs to know what packfiles are available (both are\ngenerated by git-update-server-info, usually run from update hook).\n\nStarting from appropriate object, it tries to download loose object,\nif posible, and if not then it downloads index files to know which\npackfile to download.  It walks the chain down checking which objects\nit has, and if there is one missing it downloads it.  It always\ndownloads _whole_ pack files.  It doesn't use range request... what's\nmore, as far as I know it doesn't know how to resume partially\ndownloaded packfile (hough it wouldn't re-download packfile it already\ngot).\n\n> Background: I am looking at whether yum repositories' data (currently\n> in sqlite & xml) could benefit from being a git (or very gittish)\n> database -- with a bit of re-organizing to make it git-efficient of\n> course.\n> \n> Not the data that would benefit, but rather, users pulling updates\n> from fast-moving repos (updates, updates-testing, rawhide...).\n> \n> One of the constraints is that this has to be http, and work well\n> across a universe of mirrors (that won't install or configure\n> software) and the good bad and ugly world of http proxies. Yum can be\n> taught to use the git proto, but that won't gain widespread use\n> quickly -- http is and will be the mainstay for a long time.\n\nNote that from some time we have \"smart\" http protocol, which is\nalmost git protocol proxied over http... with addition that http\nprotocol is stateless.  Default git-http-backend CGI script falls back\nto \"dumb\" protocol if client doesn't support smart http transport.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}