multi-indexed tdb

[Volker Lendecke]

On Sat, Aug 12, 2006 at 03:34:24PM -0400, simo wrote:
> As Tridge already pointed out, ldb depends only on talloc and tdb, if
> you copy out the 3 directories ldb, talloc, tdb from /source/lib and
> place them somewhere else, you will have a standalone ldb build, all you
> have to do is to cd in ldb and do: ./autogen.sh; ./configure; make

Did you try exactly those steps? For me it fails because it
can not find popt.h:

vlendec at delphin:/data/4_0/lib/ldb> make
Compiling tools/ldbadd.c
In file included from tools/ldbadd.c:37: ../ldb/tools/cmdline.h:25:18: error: popt.h: Datei oder Verzeichnis nicht gefunden
make: *** [tools/ldbadd.o] Fehler 1

> Why don't you expect it? Have you ever asked if anybody was interested?
> I am interested, and I am more than happy to make the ldb library
> compatible with C++. 

Sorry, but Samba4 does not even compile on all build farm
hosts that just compile C. Samba4 deliberately uses struct
names that conflict with function names, and it uses
state->private a lot. "private" is a keyword in C++. That's
a looong way to go.

> And which are these goals? Have you asked what are the goals of the
> people working on samba4 or more specifically on ldb?

Samba4 is a pure research project, Samba3 is production
code. Don't get me wrong, I very much appreciate the work
you are doing, we all benefit a lot from it. But it is so
far away from production code that I would not consider it
anywhere stable.

> > Or would the Samba4 developers be willing to separate out
> > the non-modular ldb part? Is that even possible?
> 
> I will tell you if you explain me what dos it mean "separate out the
> non-modular ldb part", I do not understand what it really means.

We don't need fancy stuff, we only need a multi-key
database. No mapping of attributes, no auto-generated
attributes, no server side sorting, nothing like that. Just
multi-key. And maybe multi-index for aliases. That's it. If
I copy all of lib/ldb as proposed I get tons of stuff I do
not need.

> Who is responsible when something breaks in samba3?

The one who checks the stuff in. Just look at the Samba4
build farm. Nobody is responsible for that in Samba4 land.

The fact that Samba4 is Linux only is very well displayed by
the fact that tdb_firstkey/tdb_nextkey in Samba4-tdb (now in
Samba3) broke on *ALL* non-Linux hosts when actually being
excercised. And nobody so far bothered to port my fix to 4,
even although I explicitly pointed out that the fix might
also be interesting for Samba4.

> talloc_steal() will not go away from ldb, as it is part of the way ldb
> has been thought from scratch, especially since we use a completely
> async interface.

talloc_steal is made for people smarter than all of us
working on Samba3 are.

Every time I used talloc_steal in Samba3 I had to think
hard to get it right. This is not a good sign for long-term
maintainability. Tricky code sooner or later gets broken,
and complex talloc hierarchies lead to very subtle code.

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/4bd01eed/attachment.bin