samba-technical@lists.samba.org
[Top] [All Lists]

Re: multi-indexed tdb

Subject: Re: multi-indexed tdb
From:
Date: Sat, 12 Aug 2006 08:53:05 +0200
Volker,

I know this may well be beating a dead horse, but I think the
discussion of where to go with tdb in Samba3 is useful.

 > In the 2-3 hours I took to get some core ldb parts out of
 > Samba4 I did not find a way to sanely separate it. For
 > example ldb.h is 1330 lines with for example all the OIDs
 > for the extended operations is something we don't need in
 > Samba3, and this will only create big merging pain later on.

ok, so why separate it out at all? ldb is already designed to be built
standalone (see Makefile.in in lib/ldb).

Why would you delete all the OIDs ? They don't do any harm. You would
grab all of lib/ldb/ as it is.

Regarding the merging pain, the ldb API that Samba3 would need hasn't
changed for quite a while, so the merge would consist of running
cp. It would only be painful if you tried to grab only part of ldb.

Samba3 already links to lots of libraries, but we don't tell people to
grab just some parts of krb5, openldap, readline etc and pull in just
the lines of source in those libraries that are needed for Samba. The
same should apply for ldb. The only dependency ldb has is talloc and
tdb, which Samba3 has.

 > Second, I have the impression that ldb right now is the only
 > area in Samba4 where development is happening. I'll rather
 > wait some months until that has settled a bit.

well, development is certainly happening, but it is happening with a
stable base API (the API you would use), and with a quite decent test
suite so we know things don't break.

If you wait a few months months then switch to ldb then you will need
a second format change for the long lived database files people
use. Minimising the number of format changes is really worthwhile.

 > Third: Right now we don't need all of ldb, the current
 > tdb_multikey.c file is 586 lines. I suspect that ldb will be
 > at least 2-3 times that size. And being burnt very badly by
 > 3.0.23 I'm right now very careful with complex code. I don't
 > want to screw up another release, one is enough for a while.

ok, so why not use code that has an extensive test suite, that has
been tested and proven over quite a long time, and that offers room
for growth?

I know you just want a 'simple' solution now, but I think it is worth
considering the slightly longer view. 

Cheers, Tridge

<Prev in Thread] Current Thread [Next in Thread>