httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: apache-2.0 STATUS
Date Tue, 18 Apr 2000 21:29:33 GMT
On Tue, 18 Apr 2000, Tony Finch wrote:
> >       * Provide a sane API for handling the request's environment variables.
> >  +
> >  +    * configuration option to use *DBM
> >  +
> >  +    * add SDBM into src/lib/sdbm/ as a default/fallback DBM implementation.
> >  +      SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM support.
> I've been talking about this with Dirk recently. We need a decent
> general-purpose hash table implementation to use for the name-based
> virtual host index (and it could replace the existing hash for the
> IP-based vhost index) and the environment and the file index used by 
> mod_mmap_static etc. etc.

For a hash table implementation, I would recommend extracting the relevant
code from Python. It has a compatible license and it has been optimized
all to hell over the past eight years. Between 1.4 and 1.5, a number of
"mathematics theorists/heavyweights" tackled the design and improved it
even more. I doubt that we could improve on it.

However, you mix the hash table discussion with something about DBs...
Were you talking about a general hash table, or about hash table indexes
into a file-based database?

> Dirk suggested using Berkeley DB (it'd have
> to be 1.85 or 1.86 for license reasons; most people use 1.85 to avoid
> file format compatibility problems). It has some significant technical
> advantages over SDBM (endian-independent, no size limits) which make
> me prefer it; Is SDBM more portable or does it have some other
> attribute that makes it preferable?

The old Berkeley DB wouldn't be too bad. It does have a compatible
license.  (IMO, endian-independent is probably moot -- who transports
binaries dbs?) The size limit is a big win over SDBM. Have the bugs been
worked out of DB? I seem to recall that it corrupts the file every now and

SDBM is tiny, lightweight, and public domain. The latter point means that
we can slap an ASF copyright and license on the thing, and maintain and
improve it at will (e.g. APR-ize the thing).

I don't recall if DB has file locking or not. The SDBM solution that I'd
be checking in (per that STATUS item) does.

SDBM makes best sense as a fallback. In all cases, GDBM is going to be the
"best" answer, short of a full SQL database.

Note: I intend to create a thin "ap_dbm_*" layer and then slide in *DBM
implementations under that, according to ./configure switches.


Greg Stein,

View raw message