Re: libgit2 - a true git library

["Shawn O. Pearce" <spearce@spearce.org>]

Pierre Habouzit <madcoder@debian.org> wrote:
> 
> 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:

Agreed.

>   * proper namespacing (e.g. OBJ_* looks like failure to me, it's a way
>     too common prefix);

Fixed.  Its now GIT_OBJ_*.

>   * 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.

Fixed, types now end in _t.

> And write that down _first_. It's not a lot of work, but it must be
> done. Working on a library really asks us to create something coherent
> for our users.

How about this?

http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
 
> Second, if we want this to be a successful stuff, we all agree we must
> let git be able to use it medium term. That means that when git-core is
> experimenting with new interfaces, it will probably need to hook into
> some more internal aspects of the library. This is a problem to solve
> elegantly, linking git against a static library won't please a lot of
> vendors and linux distributions, and exporting "private" symbols is a
> sure way to see them being abused.

Private symbols are a problem.  On some systems we can use link
editing to strip them out of the .so, but that isn't always going to
work everywhere.  I've outlined the idea of using double underscore
to name private functions, and we can link-edit out '*__*' if the
platform's linker supports it (e.g. GNU ld).
 
> Last but not least, I believe parts of git-core are currently easy to
> just take. For example, any code *I* wrote, I hereby give permission to
> relicense it in any of the following licenses: BSD-like, MIT-like,
> WTFPL.

Yea.  We could try to do that.  I don't know how far it will get us,
but if we have to "steal" code we can rip a good part from JGit.
Its BSD-like, but has that "icky Java smell" to it.  :-)

Before worrying about where we get implementation bits from I'm
more interested in trying to get a consistent view of what our
namespace looks like, and what our calling conventions are, so we
have some sort of benchmark to measure APIs against as we add them
to the implementation.

-- 
Shawn.