(Fwd) Re: gdbm end of life

--- Forwarded mail from Peter Neilley <address@hidden>

Date: Mon, 5 Apr 1999 16:32:28 -0600 (MDT)
From: Peter Neilley <address@hidden>
Subject: Re: gdbm end of life
To: address@hidden

> So, you link the readers with a different version of gdbm than the
> writers? Or you use your modified version of gdbm when building the
> ldm in lieu of what we provide?

We do not change the version of gdbm in the LDM.  What you guys
link with/distribute is sufficient.  Changes only occur on the
reader (i.e. WEATHER) side.

Source-code versions of weather distributions are shipped with the
Neilley-hacked  GDBM code.  The version of GDBM that I use is one that
is fairly recent (1997?) and included support for both big and little
endian gdbm files.  I further hacked that code so that the detection of
big/little endian is done on the fly rather than a static make-time
switch.  The big/little endian support was important so that sites
that create gdbm files on big endian machines and write them to
a network-shared database, can read them using 'weather' run on a little
endian machine and vis-versa.  (e.g. write gdbm files using a
solaris-based LDM, read gdmb files from a LINUX version of Weather).
This also has allowed institutions to share gdbm files freely without
worry about the platform that the LDM was originally run on.


> The gdbm we distribute is 1.7 from 1993.
> The most recent release of gdbm is 1.7.3 from July 1995 or before.
> We have to hack gdbm to get it to work in our portability framework.
> It is just one feature of one program. The feature can be supported by
> public interfaces (<ndbm.h>). So, why should we include gdbm in our
> realm of responsibility? There does not seem to be any active development
> of gdbm; it is a dead end. The open platforms (LINUX, FreeBSD, ...)
> seem to be using berkeley db as the default, although some include gdbm as
> well.
>
> When we first started the ldm project, the set of libraries one could
> expect to find on a *NIX system was not very well defined. (Actually,
> when we first started, we supported VMS :-)). Now we pretty much know
> what to expect. It is just plain good programming practice to use
> system interfaces whenever you can. This way, one can drop in whatever
> implementation (system default, Berkeley DB, gdbm, ...) one wants just
> by relinking. We are also dropping librexexp because the functionality
> is there in the OS libraries.
>
>

I understand your desire to simplify and standardize, but at the
risk of being brash, I counter that "good engineering practice
supports the needs of the clients".  Decisions as to which features
are supported should be (at least partly) based on the needs of
your clients.  Just because there has been no active development of
gdbm does not seem to be a sufficient reason to drop it.  I'm sure
there are large portions of a Unix-kernel or utilities that have been
static for quite a long period.  You mention you need to hack gdbm
code to make it work in you framework, but isn't that true about all
of your supported code?  As your framework is modified, you need to
propagate that framework to all your code, including gdbm.

Anyway, it sounds like you will be shipping LDM V+1shortly (weeks or so).
It is unlikely that I will have the time to update weather the support
the ndbm model, particularly given all the hacking that I will have to
do to make it work correctly.  Therefore, institutions that want to
continue to use gdbm METAR files in WEATHER (only 2-3 out of 45 don't)
will have to avoid LDM-upgrades or compile it themselves with the
options you mention above.

Ugh.

Peter



---End of forwarded mail from Peter Neilley <address@hidden>