Pierre Habouzit wrote:
On Fri, Oct 31, 2008 at 05:07:04PM +0000, Shawn O. Pearce wrote:
During the GitTogether we were kicking around the idea of a ground-up
implementation of a Git library. This may be easier than trying
to grind down git.git into a library, as we aren't tied to any
of the current global state baggage or the current die() based
error handling.
I've started an _extremely_ rough draft. The code compiles into a
libgit.a but it doesn't even implement what it describes in the API,
let alone a working Git implementation. Really what I'm trying to
incite here is some discussion on what the API looks like.
I know this isn't actually helping a lot to define the real APIs, but we
should really not repeat current git mistakes and have a really uniform
APIs, meaning that first we must decide:
* proper namespacing (e.g. OBJ_* looks like failure to me, it's a way
too common prefix);
As it's the git-lib, all public functions should almost certainly be
prefixed with "git" or "git_". I favor "git_".
* proper public "stuff" naming (I e.g. realy like types names -- not
struct or enum tags, that I don't really care -- ending with _t as
it helps navigating source.
*_t types are reserved by POSIX for future implementations, so that's
a no-go (although I doubt POSIX will ever make types named git_*_t).
Apart from that, please consider reading Ulrich Drepper's musings on
library design at http://people.redhat.com/drepper/goodpractice.pdf
It's pretty short but brings up nearly all the crucial points one really
don't want to forget.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
