From: Christian Meder <chris@absolutegiganten.org>
To: Jan Harkes <jaharkes@cs.cmu.edu>
Cc: git@vger.kernel.org
Subject: Re: First web interface and service API draft
Date: Fri, 22 Apr 2005 22:57:03 +0200 [thread overview]
Message-ID: <1114203423.3207.24.camel@localhost> (raw)
In-Reply-To: <20050422142342.GG30915@delft.aura.cs.cmu.edu>
On Fri, 2005-04-22 at 10:23 -0400, Jan Harkes wrote:
> On Fri, Apr 22, 2005 at 12:41:56PM +0200, Christian Meder wrote:
> > -------
> > /<project>/blob/<blob-sha1>
> > /<project>/commit/<commit-sha1>
>
> It is trivial to find an object when given a sha, but to know the object
> type you'd have to decompress it and check inside. Also the way git
> stores these things you can't have both a blob and a commit with the
> same sha anyways.
>
> So why not use,
> /<project/<hexadecimal sha1 representation>
> will give you the raw object.
>
> /<project/<hexadecimal sha1 representation>.html (.xml/.txt)
> will give you a parsed version for user presentation
>
> And since hexadecimal numbers only have [0-9a-f] as valid characters,
> you can still have additional directories that can be guaranteed unique
> as long as the first two characters are not a valid hexadecimal value.
> So things like /branch/linus, or /changelog/, /log/, /diff/. Yeah, you
> can't use /delta/ without looking at more than the first two characters,
> but that's where dictionaries can come in handy.
Hmm. I'm not sure about throwing away the <objecttype> information in
the url. I think I'd prefer to retain the blob, tree and commit
namespaces because I think they help API users to explicitly state what
kind of object they expect. I can't think of a scenario where I'd want a
<sha1> of unknown type. Do you have a specific use case in mind ?
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
next prev parent reply other threads:[~2005-04-22 21:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-22 10:41 First web interface and service API draft Christian Meder
2005-04-22 11:34 ` Jon Seymour
2005-04-22 12:10 ` Petr Baudis
2005-04-22 12:27 ` Jon Seymour
2005-04-22 13:32 ` Christian Meder
2005-04-22 13:30 ` Christian Meder
2005-04-22 12:10 ` Petr Baudis
[not found] ` <1114176579.3233.42.camel@localhost>
2005-04-22 22:57 ` Petr Baudis
2005-04-24 22:29 ` Christian Meder
2005-04-22 12:37 ` El Draper
2005-04-22 13:44 ` Christian Meder
2005-04-22 13:47 ` Jon Seymour
2005-04-22 14:23 ` Jan Harkes
2005-04-22 20:57 ` Christian Meder [this message]
2005-04-23 6:39 ` Jon Seymour
2005-04-22 22:45 ` Petr Baudis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1114203423.3207.24.camel@localhost \
--to=chris@absolutegiganten.org \
--cc=git@vger.kernel.org \
--cc=jaharkes@cs.cmu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).