From: Petr Baudis Date: Fri, 22 Apr 2005 22:57:33 GMT Subject: Re: First web interface and service API draft Message-ID: <20050422225733.GH21204@pasky.ji.cz> In-Reply-To: <1114176579.3233.42.camel@localhost> Dear diary, on Fri, Apr 22, 2005 at 03:29:39PM CEST, I got a letter where Christian Meder told me that... > > > / > > > > > > Ok. The URI should start by stating the project name > > > e.g. /linux-2.6. This does bloat the URI slightly but I don't think > > > that we want to have one root namespace per git archive in the long > > > run. Additionally you can always put rewriting or redirecting rules at > > > the root level for additional convenience when there's an obvious > > > default project. > > > > > > Should provide some meta data, stats, etc. if available. > > > > I don't think this makes much sense. I think you should just apply -p1 > > to all the directories, and define that there should be some / page > > which should contain some metadata regarding the repository you are > > accessing (probably branches, tags, and such). > > Hi, Hi, > remember that I want to stay stateless as long as possible so everything > important has to be encoded in the url. So somewhere in the url the git > archive to show has to be encoded. If I remove the portion how > do I know on the server side which repo to show ? since you are configured appropriately. You need to be anyway. Someone needs to tell you or your web server "this lives at http://pasky.or.cz/wit/". So you bind "this" to the given repository. No problem with an additional configuration possibility to say "at that place, clone your life place for the given repositories", but if I want to have just a single repository at a given URL, it should be possible. I'm just trying to argue that having it _forced_ to have as the part of the URL is useless; this is matter of configuration. > > > * Blob data should be probably binary ? > > > > What do you mean by binary? > > content-type: binary/octet-stream Ah. So just as-is, you mean? > > Anything wrong with putting ls-tree output there? > > ls-tree output should be in .html (see below) What if I actually want to process it by a script? > > > ------- > > > //tree/ > > > > > > Tree objects are served in binary form. Primary audience are scripts, > > > etc. Human beings will probably get a heart attack when they > > > accidentally visit this URI. > > > > Binary form is unusable for scripts. > > Why should it be unusable for a downloading script. It's just the raw > git object. > > > We should also have /gitobj/ for fetching the raw git objects. > > Everything above is supposed to be raw git objects. No special encoding > whatever. You have a consistency problem here. Raw git objects as in database contain the leading object type at the start, then possibly some more stuff, then '\0' and then compressed binary stuff. You mean you are exporting _this_ stuff through this? That's not very useful except for http-pull, if you as me. It also does not blend well with the fact that you say commits are in text or so. > > > ------- > > > //tree//diff//html > > > > > > Non recursive HTML view of the objects which are contained in the diff > > > fully linked with the individual HTML views. > > > > Why not .html? > > I think .html isn't very clear because it would > be ..../.html which somehow looks like it has > anything to do with the ancestor-tree. But it's the html version of the > _diff_ and not the ancestor-tree. Perhaps /tree/.html/diff/ ? I'd lend to ?diff= more and more. The path part of URI is there to express _hierarchy_, I think you are abusing that when there is no hierarchy. > > For consistency, I'd stay with the plaintext output by default, .html if > > requested. > > Remember that I'm just sitting on top of git and not git-pasky right > now. So there's no canonical changelog plaintext output for me. But I'm > not religious about that. But there is canonical HTML output for you? ;-) > > OTOH, I'd use > > > > /log/ > > > > to specify what commit to start at. It just does not make sense > > otherwise, you would not know where to start > > Start for the changelog is always head, but I guess that's pretty > standard. With git log you always start at the head too. If you are sitting on top of git and not git-pasky, you have no assured HEAD information at all. > If you want to start at a specific commit. Why not start > at /linux-2.6/commit/.html ? And how does that give me the changelog? > > I think the should follow the same or similar rules as Cogito > > id decoding. E.g. to get latest Linus' changelog, you'd do > > > > /log/linus > > Like I said above I think the shown head should be encoded in the > project id. I thought the project was mapped to repository? But I might just have blindly assumed that. ;-) (That does not make me like your approach more, though.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor