Re: back-bdb2 <-> back-ldbm

[Kurt Spanier <zrnsk01@zdv.uni-tuebingen.de>]

Hallvard,

On Wed, 24 Feb 1999, Hallvard B Furuseth wrote:

> Date: Wed, 24 Feb 1999 18:09:21 +0100 (MET)
> From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
> To: Kurt Spanier <kurt.spanier@zdv.uni-tuebingen.de>
> Cc: openldap-devel@OpenLDAP.org
> Subject: Re: back-bdb2 <-> back-ldbm
> 
> Kurt Spanier writes:
> > To avoid conflicts, I have moved ALL non-static functions in back-bdb2
> > into their own name-space, bdb2_ and bdb2i_, respectively. That is the
> > situation for the moment.
> 
> Oh, I see.  Personally I wouldn't have moved any files until they needed
> to be moved, but I guess that's a matter of taste.
> 

actually, my first approach to the new backend was to shift all internal
functions to the new name-space, and keep the entry functions
(ldbm_back_add, ldbm_back_search ...) to their original names. Since
'back-bdb2' will be build BEFORE 'back-ldbm' and the respective libraries
will be ar'ed in that order to 'libbackends.a', I HAD a total replacement
of back-ldbm by 'back-bdb2' :-) Only when I shifted to backend specific
names even for the entry functions, I had both backends again available at
the same time.

As I said, I have discussed with Kurt to totally replace back-ldbm by
back-bdb2, once you configure --with-bdb2, but he argued, that we should
stay with the possibility to use a GDBM backend together with a BDB2
backend. Maybe, Kurt should comment on that.

Of course, once we have that decission to totally skip back-ldbm when we
use back-bdb2 (which I would strongly support, not because I am the
principal developer of back-bdb2, but because NDBM/GDBM CANNOT be used
at the same time due to the #ifdefs #elif and whatever in ldbm.[ch]),
code hassels could be reduced to some extend by re-using the functions.

> > Now, how could you merge certain source files, when functions in those
> > files will call backend-specific versions of functions that completely
> > differ from each other ?
> 
> Compile bdb2 with -DUSE_BDB2 or something, and maybe back-ldbm with
> -DUSE_LDBM.  Then say
> 	#ifdef USE_BDB2
> 	#  define db_some_func	bdb2i_some_func
> 	#else
> 	#  define db_some_func	ldbm_some_func
> 	#endif
> and call/declare `db_some_func' in the .c file and proto-*.h file
> instead of calling/declaring `bdb2_some_func' & `ldbm_some_func'.
> 
> > You had to decide on the functions' name at run-time, depending in the
> > question, which backend you really use at the moment.
> 
> I don't see why anyone would use ldbm if they had bdb2, but if you do
> need to support both at the same time, that's easy enough:
> back-bdb2/foo.c could contain simply
> 	#include "../back-ldbm/foo.c"
> or Makefile could compile ../back-ldbm/foo.c or copy it.
> back-bdb2/Makefile would compile with -DUSE_BDB2, back-ldbm/Makefile
> with -DUSE_LDBM.
> 
> > Merging the code of both backends again would also be no alternative.
> > Unless you really prefer one backend over the other, you had to include
> > a lot of run-time decision code (not #ifdef, since that compile-time
> > decision), that would make the implementation much more ugly, I fear.
> 
> I don't quite understand what you mean here, but I did assume that only
> some files would be merged.  Files that are too different would have
> gotten an #ifdef mess which was worse than having 2 separate files.
> 
> > But if you have a look to
> > libraries/libldbm/ldbm.c and include/ldbm.h it's easy to see, that
> > Berkeley DB really is preferred over the others, once you have it. So
> > running the others in parallel is a non-possibility, even with the 'old'
> > back-ldbm. Why not really shut off back-ldbm when you configure
> > '--with-bdb2' ? This would indeed give the possibility to merge the code
> > again.
> 
> Agreed.  And like I said, it wouldn't be hard to hack it to support both
> anyway, if someone really wants it.
> 
> -- 
> Hallvard
> 

Kurt


----------==========#########>>>>>ZDV<<<<<#########==========----------

X.500:                                              Tel.:
   Kurt Spanier, Zentrum fuer Datenverarbeitung,      +49 7071 29-70334
   Universitaet Tuebingen, DE
SMTP-Mail:                                          FAX.:
   kurt.spanier@zdv.uni-tuebingen.de                   +49 7071 29-5912
Snail-Mail:
   Dr. Kurt Spanier, Zentrum fuer Datenverarbeitung,
   Universitaet Tuebingen, Waechterstrasse 76, D-72074 Tuebingen
PGP-Public-Key:
   finger "Kurt Spanier"@x500.uni-tuebingen.de

----------==========##########>>>>>@<<<<<##########==========----------