apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util/src/dbm apr_dbm.c
Date Sat, 09 Dec 2000 00:09:04 GMT
On Fri, Dec 08, 2000 at 12:29:47PM -0600, William A. Rowe, Jr. wrote:
> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > Sent: Friday, December 08, 2000 11:31 AM
> > 
> > >   Log:
> > >     Document and address several problems with apr_dbm - including;
> > >   
> > >        make apr_dbm_open args sane in respect to both apr and dbm
> > >        note absurdity of apr_dbm_freedatum in a pool-managed implementation
> > >        note obscurity of apr_dbm_geterror in relation to apr
> > 
> > I would just like to go on record as saying that the dbm portion is the
> > incorrect solution.  PHP has already solved this exact problem in a
> > portable way for far more databases.

You're referring to the "dba" code in PHP4. I've looked at it quite a bit
when I set up aputil/apu_dbm.c, to see how theirs compared to what I had
already set up in mod_dav 1.0 (which is where apu_dbm's code came from).

> > Why are we duplicating their work?

There isn't an intent to duplicate their work, but it does happen to be
because:

1) their code is designed to be integrated into PHP rather than as a
   separable library
2) it does not use pools
3) it does not support SDBM
4) it does not have the freedatum or geterror calls (in fact, I see their
   GDBM code does a printf() for one of the error cases!)
5) this code is total cake. there isn't any true leverage (in terms of
   maintenance) by trying to use their code.

We support SDBM and GDBM. They support CDB, DB2, DB3, DBM, GDBM, NDBM.

> > Their license is completely compatible with ours, so 
> > we should just be able to take their code and move on.

Well, there are acknowledgement clauses and things that we would then need
to incorporate. Compatible, yes. Easy?

> In leiu of or in addition to sdbm, fine.  But in terms of a pool memory wrapper
> for dbm access, that still has a benefit.

Right.

> We [should] eliminate (or shield) the freedatum in the retrieve call, copying 
> the datum into the pool.  The user frees the pool and all goes away.  Advantages 
> include the fact that the datum is modifiable in-place, and persist after the 
> database is closed (if this behavior is desired, as it may be in Apache or other 
> threaded pool-based applications.)

The user can make the copy into the pool if they desire. We should not be
adding that overhead unilaterally.

However! We should register a cleanup in the GDBM case, and put a note in
the doc about the duration of the datum's contents. I just never got to the
former, and didn't think about the latter until this discussion. There is
also one more entry point that we need in the API (to discover the file
names used, so that a caller can delete/rename/move them if desired).

>...
> One last observation, sdbm.h does _not_ belong in apr-util/include/ and neither
> does the apu_private stuff.  Suggest we move those on out of there, but where?
> apr-util/include/private?  We don't need arch/ anything, since headers shouldn't
> change the same way in apr-util (it's already cross-platform, right :-?)

We could move apu_private to a subdirectory, but why? A handy subdir was
available in APR, so that was an easy choice to hide the include file. I say
that we leave the file and simply tell people "you're an adult. listen to us
when we say don't include it."

> Note we don't appear to have an apr-util.h just yet for compiled-in features
> of the lib... we need one, no?

if/when we have separable features.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message