multi-indexed tdb

[Volker Lendecke]

On Sat, Aug 12, 2006 at 08:53:05AM +0200, tridge at samba.org wrote:
> ok, so why separate it out at all? ldb is already designed to be built
> standalone (see Makefile.in in lib/ldb).

Hmmm. Just tried it. Does not work, this seems to depend on
other parts of Samba4.

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

Sorry to be negative, but this would essentially mean a fork
of ldb. Even tdb and talloc have gone into different
directions. The diff between the respective Samba3 and
Samba4 versions is considerable. For example I don't expect
Samba4 to follow my attempts to make that compile with C++
to see additional warnings. We just have different goals.
And as there is quite a bit of development being done in
Samba4 ldb right now and this from the start is a lot more
complex code, I would expect both to diverge at a much
quicker pace.

The only way to keep both together would be to really
separate the stable ldb_tdb base API and "link" them into
one directory. But this from my point of view is a
considerable effort.

Or would the Samba4 developers be willing to separate out
the non-modular ldb part? Is that even possible?

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

Who would be responsible if the build farm breaks after such
a merge? Looking at the Samba3 vs Samba4 build farm results
I get the impression that building on anything but Linux is
not a priority for Samba4. I would not like to lose the
other Unixes.

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

Need to check that when I get it to compile at all. You
might be right. But for example with ldb_ildap I fear that I
have to import all of gensec to get it.

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

I went through a *LOT* of pain understanding and fixing the
warnings all the archane machines gave me. I'm a bit
reluctant compiling many modules that we never use and which
just don't meet the coding standards we have in Samba3 these
days. I don't have specific examples, but wading through the
Samba4 build farm can't be called fun these days.

For example I would want to remove the use of talloc_steal
from ldb, something that Samba4 will probably never follow.
But in Samba3 we came to the conclusion that talloc_steal
can very easily lead to complex code.

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

Don't get me wrong, I really would like to benefit from ldb,
but our goals are just way too different.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060812/9ec6f874/attachment.bin