httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: lib/aputil
Date Tue, 28 Nov 2000 07:06:01 GMT
On Mon, Nov 27, 2000 at 09:56:53PM -0800, wrote:
> I have some questions about this library.  I said the last time that we
> discussed this that if we are putting a package into the lib/ directory,
> then it needs to be a full package.  What was put into aputil is a wrapper
> around some db code that, AFAICS, is not useful outside of Apache.

As I said in the checkin comment, the code there is just a *start*. Sure, it
is just a single piece of code. I expect the rest of src/ap/ to move in
there, but didn't do it because it is a rather large change and requires at
least some semblance of discussion :-)

And apu_dbm is quite useful outside of Apache. I intend to use it in
Subversion. (admittedly, from an Apache module :-).

> I'm also not really sure why this code is using APR.

apu_dbm uses APR because it uses pools, which are used by SDBM.

> AFAICS, there
> is no portability issue that needs solving in this code though.

Not in apu_dbm. It is intended to be a cover over *DBM. It is used by
mod_dav to implement property databases and the lock database. It can also
be used by mod_auth_dbm to store passwords in any DBM type.

> It is
> using APR file definitions, but it isn't using APR files.

SDBM does. apu_dbm passes values to SDBM.

> It is using
> apr_pools, but I'm not convinced pools makes much sense here in any
> context other than Apache.

What?!! Pools are kick ass. How can you possibly say they don't make sense
for anybody but Apache?

> Pools are a great memory management scheme,
> but what are they buying us here?

When mod_dav uses apu_dbm, and the request ends, I want to be sure that all
of the SDBM-created files and locks and memory are closed/discarded. That is
what pools are for, and which is why they are passed into SDBM.

> As far as I can tell, the pool is
> required because we are using our own hacked version of sdbm that requires
> pools.  But why did we ever do that to sdbm?

Because that is our copy of SDBM, and it made a ton of sense to APR-ize the
darn thing. There was some hacked up stuff in there to deal with different
platforms, which is now gone. We also get the benefits of pools. We get
portability of SDBM, which is cool because we can always use it as a
fallback DBM whenever one isn't available in the operating system. (note
that mod_auth_dbm uses SDBM on Win32)

> The only other place we use
> the pool, is to allocate a structure that could easily be allocated
> outside of the function.

Eh? It is also used for files within SDBM. Since apu_dbm could call SDBM, it
needs to pass a pool. The structure you refer to (I presume apu_dbm_t) is an
internal, opaque structure. It should not be exported, which means it must
be internally allocated.

> Also, this code refers to DAV, which ties it to the server.  If this code
> is only valid inside Apache, then it should not be in a lib/ project.  If
> this code is useful outside of Apache, then the DAV
> references need to be removed.

Agreed. That was a simply typo, and I've already committed the fix.

> Regardless, this REALLY needs to become a full package ASAP,

What is wrong with a simple Makefile? Why do we have to autoconf the darn
thing, or make it standalone, or whatever?

Let's get our work done, not spend time on packaging something that is a
*long* ways from ever being split from Apache. We knew up front that APR was
going to be separated, so we spent a lot of time packaging it. Doing the
same for SDBM or aputil is just wasted effort.

> or it
> should be moved back inside of Apache IMHO.  At the very least, we need to
> actually decide what belongs in this library now.

At least everything in src/ap/. Possibly a good number of util_* that is
sitting in src/main/ (e.g. the XML stuff, maybe some conftree stuff, things
like "getword" and friends, etc)

> It seems to me that
> this library has been discussed a lot, but nothing was ever decided.

Simply because it was a lot of talk and nobody took a first step :-) You
can't have decisions if nothing ever happens :-)

> If
> something was decided, could we put a document in that directory
> explaining what it's purpose is and how it will proceed.

Done. (well, an initial rev)


Greg Stein,

View raw message