Re: Libification project (SoC)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

[please do not cull the Cc: list]

On Fri, 16 Mar 2007, Rocco Rutte wrote:

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

Why? For some tasks, it should be 1) easier, 2) more elegant, and 3) 
faster to write a function which re-initialises the static variables.

Of course, if you want to work with multiple repos _at the same time_, 
this does not help you. But frankly, we don't support that with core-git, 
so why should we in libgit?

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

Nope. It is _not_ a complete rewrite. More likely, it is minimal 
adjustments. It's not like we will replace apples with cars...

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

We already _have_ the data structures!

Also, in my experience, defining a complete API, and only after that, 
implement it, never works. Rather, start with a _small_ part you want to 
do. Define a clean API _just for that part_. Implement it. Verify that it 
indeed does what it should do (and that means not just _you_ should verify 
it, but it should be stress tested on the list).

We don't have to create the whole world in one day, you know?

Ciao,
Dscho