httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <>
Subject Re: cvs commit: apache-2.0 STATUS
Date Wed, 19 Apr 2000 03:57:21 GMT
Greg Stein <> wrote:
>On Tue, 18 Apr 2000, Tony Finch wrote:
>> 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.

Algorithms are easy to come by (but most of the implementations that I
have seen recently are shite -- perl's and python's would be OK), but
for an implementation that fits in well with the rest of Apache (or
rather APR) it would have to be basically rewritten from scratch --
there's not much to a hash table, and once you have changed the
function prototypes and the allocation library there's not much of the
original left.

>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?

Berkeley DB can be used in a mode where it's just an in-memory hash
table. It's can obviously be used for many more interesting things by
the server.

>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?)

>From the point of view of an ISP that doesn't want to be tied to a
platform because of the data files used by our customers, endian-
independence is a big win.

>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 then.

I haven't heard of that. Do you have any authoritative references?

>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).

But then we will be less able to make use of improvements made by the
perl guys.

>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.

Berkeley DB 2 does, but that doesn't have a compatible license.

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

No, Berkeley DB is better than GDBM because of the endian issue and
licence; TTBOMK in other respects it is equal.

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

Of course.

334 butter-side-down in the diaper bucket

View raw message