Re: gdbm end of life

> some quick thoughts.  First is ugh, which you probably guessed.
> This is difficult for more than just me.  We have alot of apps
> here at RAP that use gdbm beyond 'weather'.  Same is true elsewhere.

What I propose doing is changing the interface that 'pqact' uses internally,
and dropping inclusion of gdbm from the ldm source and binary releases.
(The program 'pqact' is the only one in our distribution which uses gdbm.)
If a site like RAP is wedded to the gdbm file format, there are a couple
of options. Both require that the site build from source rather than
obtain a binary release.

1) Link the ndbm interfaced pqact against the gdbm library.
Since gdbm supports the ndbm interfaces, the ndbm calls in pqact
will be handled by libgdbm, and your other applications won't
know any different.

2) When compiling pqact:filel.c, #define USE_GDBM.
I have left the gdbm interfaces available, the default is to use
ndbm.

> What kind of time frame are you thinking about for the drop of
> gdbm support?

I'm working on an overdue ldm release now, which has things done as I describe.
The point of this release is to provide correct LINUX support. (It seems we
have
not been able to do this yet.) It is overdue in the sense that LINUX sites are
clamoring for it and they are becoming legion.

> A joint release of ldm and weather sounds good,
> assuming I can get the time to add support ndbm.  I'll have to keep
> gdbm support since alot of institutions archive gdbm files and
> use weather to view archived data.
>
> As you probably know, I hacked the gdbm source to deal with the
> concurent access issue by disabling it from the reader side.

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?

> This was based on the analysis that collisions were rare (1:ten million
> reads), and even if they occurred, could be recovered from quickly and
> easily. I'll have to do the same to ndbm, assuming source code is
> available.

Or, just use the ndbm interface to gdbm. Or, use the ndbm interface to
the Berkeley db package http://www.sleepycat.com/ which deals with
concurrent access correctly.

> Why drop gdbm?  Is it just a pain to hang onto?  Or does retaining it
> prevent some new role/features of the ldm?

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.

-glenn