SDBM is out (was: Porting to RISC OS)

[Matthias Andree]

On Sun, 07 Sep 2003, Stefan Bellon wrote:

> > ftp://tsx-11.mit.edu/pub/linux/sources/libs/
> >  sdbm.tar.Z . . . . . . . . . . . Feb 25  1992     63k
> 
> > Do we really want to add some 13-year-old library stuff, sdbm?
> 
> Quite certainly not! SDBM is part of Apache and still maintained.

> > I don't think so if it doesn't have any advantages and isn't
> > necessary to work.
> 
> If another operating system doesn't have Berkeley DB and TDB is too
> slow and QDBM is not ported, why not give the opportunity to use SDBM?

I've looked at the NetBSD port collection and Google to find SDBM
standalone, only found this public domain 1990/1992 stuff.

SDBM is out for

1. technical reasons

   SDBM is unsupported by our current test suite, all other data bases
   (since QDBM has been switched to use the quicker native depot(3) API
   rather than the slower wrapper relic(3) API) are supported.

   I do not know of any system that doesn't support at least one of BDB,
   TDB and QDBM. In fact, as RISCOS works with TDB, we don't actually
   need QDBM, I rewrote it just for the fun of it.

   The original public domain SDBM code by Ozan S. Yigit from 1992
   doesn't compile.

2. legal reasons.

   The Apache APR SDBM code is licensed to us under the Apache Public
   License v1.1. We cannot link such code into bogofilter which is under
   the GNU General Public License v2 without causing conflicts and
   special provisions, requesting and passing special permissions and
   all that.

3. morale reasons.

   There is not the slightest trace of evidence that SDBM might offer
   _anything_ that the other data bases do not offer, and your
   portability concerns are academic.


Background information:

David Relson is communicating a lot behind the scenes, asking for
advice, offering solutions, making suggestions, critizing code. He and I
have consulted each other about the integration of your RISCOS code, and
we chose to take it because the data base stuff looked generally useful
and the RISCOS changes to the baseline source were minor and compatible
with other systems, and the real specific stuff could easily go into a
sub directory.

However, somewhere a line must be drawn for support of a theoretical
system that no-one has shown so far and that is a lot of effort. It
doesn't make sense to carry around untested "just-in-case" code that
breaks the first day it's put to the test. From that POV, supporting
multiple data bases is dangerous already because we'll likely have most
users test BerkeleyDB, since that's the default and ships with most
systems.

Gyepi added TDB code for alleged BerkeleyDB breakage I couldn't ever
reproduce except with known-broken bogofilter versions.

You added QDBM code, I rewrote the whole stuff, redesigning it and
fixing bugs, but how many users of QDBM will we have? QDBM has no
migration path for robustness, if bogofilter doesn't exit cleanly a
single time, your data base is no more than a pile of junk.

How well will the code be tested in real life? We know BerkeleyDB is
tested by hundreds of users in real life. We know TDB is tested by
thousands of users every day, in Samba. How about QDBM?

Note: I do not trust a user who says "it works for me" unless he
reported a condition that led to a severe malfunction, has been given a
fix for the problem and confirmed that particular test working, with
testing instructions. Unless of course the "user" is in fact an engineer
who systematically tried to break the code.