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
* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.