From: Rocco Rutte <pdmef@gmx.net>
To: git@vger.kernel.org
Subject: Re: Libification project (SoC)
Date: Fri, 16 Mar 2007 13:09:58 +0000 [thread overview]
Message-ID: <20070316130958.GD1783@peter.daprodeges.fqdn.th-h.de> (raw)
In-Reply-To: <Pine.LNX.4.63.0703161251200.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
* Johannes Schindelin [07-03-16 12:54:52 +0100] wrote:
[...]
>Isn't this an awfully long shot?
>I'd be happy if the libification project resulted
>- in a (static!) libgit.a which can be linked to qgit or similar (being
> reentrant, or at least optionally so, and not die()ing all the time),
> and
>- which does not fix the API yet (at least for the most parts).
>We _can_ -- once we agree on a stable API -- expose _some_ functions in a
>libgit.so, but that does not have to be the goal for the first step!
First, I think that would be some cleanup "only" since that basically
would mean to
1) make all functions die()ing return some value and handle it and
2) wrap all static vars into structures and pass them around
If you don't choose a design before wrapping things up in structures,
you'll probably end up having one structure per source file (at least
too many structures).
Porting things like qgit to it or writting proper perl/python bindings
is wasted time since you'd have to rewrite all of it once you decided
which functions to expose and which structures to use (calling the
main() routines of builtin's doesn't count as real libifaction, it would
rather be a performance improvement only).
I'd simply try to find a rough consensus on the data structures and the
layer model before starting the project, solve 1), afterwards implement
2) according to it. While 2) happens it would make sense to try to
develop perl, python, C and C++ bindings in parallel to find out early
enough whether the design details chosen are useful for real consumers
outside the git-* tools.
You could put big fat warnings everywhere that parts of the API which
are exposed are heavily unstable and likely subject to change and that
programmers using them will have to frequently start over. Once it turns
out that all the git-tools and all "reference consumers" work it, you
can do some cleanup to get to the final first API version after the
libification project is done.
bye, Rocco
--
:wq!
next prev parent reply other threads:[~2007-03-16 13:10 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-16 4:24 Libification project (SoC) Luiz Fernando N. Capitulino
2007-03-16 4:59 ` Shawn O. Pearce
2007-03-16 5:30 ` Junio C Hamano
2007-03-16 6:00 ` Shawn O. Pearce
2007-03-16 6:54 ` Junio C Hamano
2007-03-16 11:54 ` Johannes Schindelin
2007-03-16 13:09 ` Rocco Rutte [this message]
2007-03-16 15:12 ` Johannes Schindelin
2007-03-16 15:55 ` Nicolas Pitre
2007-03-16 16:13 ` Johannes Schindelin
2007-03-16 16:26 ` Nicolas Pitre
2007-03-16 18:22 ` Steve Frécinaux
2007-03-16 18:53 ` Nicolas Pitre
2007-03-18 13:57 ` Petr Baudis
2007-03-16 23:26 ` Johannes Schindelin
2007-03-16 16:17 ` Shawn O. Pearce
2007-03-16 18:20 ` Marco Costalba
2007-03-16 18:38 ` Marco Costalba
2007-03-16 18:59 ` Nicolas Pitre
2007-03-16 21:07 ` Marco Costalba
2007-03-16 23:24 ` Johannes Schindelin
2007-03-17 7:04 ` Marco Costalba
2007-03-17 17:29 ` Johannes Schindelin
2007-03-16 19:09 ` Andy Parkins
2007-03-18 14:08 ` Petr Baudis
2007-03-18 23:48 ` Johannes Schindelin
2007-03-19 1:21 ` Petr Baudis
2007-03-19 1:43 ` Johannes Schindelin
2007-03-19 2:56 ` Theodore Tso
2007-03-19 3:55 ` Shawn O. Pearce
2007-03-19 14:57 ` Johannes Schindelin
2007-03-19 16:28 ` Linus Torvalds
2007-03-19 16:32 ` Linus Torvalds
2007-03-21 11:17 ` Andreas Ericsson
2007-03-21 17:24 ` Linus Torvalds
2007-03-22 9:51 ` Andreas Ericsson
2007-03-19 7:01 ` Marco Costalba
2007-03-19 9:46 ` Steve Frécinaux
2007-03-19 10:33 ` Steve Frécinaux
2007-03-19 12:37 ` Johannes Schindelin
2007-03-19 12:52 ` Petr Baudis
2007-03-19 13:55 ` Johannes Schindelin
2007-03-19 13:04 ` Marco Costalba
2007-03-16 12:53 ` Petr Baudis
2007-03-16 13:47 ` Luiz Fernando N. Capitulino
2007-03-16 14:08 ` Petr Baudis
2007-03-16 18:38 ` Luiz Fernando N. Capitulino
2007-03-16 23:16 ` Shawn O. Pearce
2007-03-17 19:58 ` Luiz Fernando N. Capitulino
2007-03-18 5:23 ` Shawn O. Pearce
2007-03-18 5:52 ` Junio C Hamano
2007-03-18 16:18 ` Luiz Fernando N. Capitulino
2007-03-18 19:31 ` Junio C Hamano
2007-03-19 16:09 ` Luiz Fernando N. Capitulino
2007-03-18 21:15 ` Nicolas Pitre
2007-03-16 15:16 ` Johannes Schindelin
2007-03-16 8:06 ` Johannes Sixt
2007-03-16 8:58 ` Matthieu Moy
2007-03-16 11:51 ` Johannes Schindelin
2007-03-16 12:55 ` Petr Baudis
2007-03-17 2:24 ` Jakub Narebski
2007-03-17 5:22 ` Shawn O. Pearce
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=20070316130958.GD1783@peter.daprodeges.fqdn.th-h.de \
--to=pdmef@gmx.net \
--cc=git@vger.kernel.org \
/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).