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: httpd-2.0/srclib/sdbm .cvsignore Makefile.in sdbm.c sdbm.h sdbm_hash.c sdbm_lock.c sdbm_pair.c sdbm_pair.h sdbm_private.h sdbm_tune.h sdbmlib.dsp
Date Sat, 09 Dec 2000 00:12:17 GMT
On Fri, Dec 08, 2000 at 03:52:26PM -0800, rbb@covalent.net wrote:
> 
> > > > > >   no longer needed. this is picked up from apr-util instead.
> > > > > 
> > > > > Warning; anything hiding in a distro folder of a source branch in
> > > > > apr (such as mm, sdbm) should remain invisible to the apr and
> > > > > apr-util lib consumers.  That means mod_auth_dbm.c must be hacked
> > > > > for the apr_dbm mechanism, before we roll.
> > > > 
> > > > Huh? sdbm.h is exported by APRUTIL. It is a publically available export.
Or,
> > > > it should be at least.
> > > 
> > > Then the header name at the very least needs to change.  As it is now, if
> > > we install Apache on a machine that already has sdbm, we will break things
> > > horribly.
> > 
> > Well, that's always been the case :-)
> > 
> > Hmm. I don't think that I'd have a problem renaming SDBM entry points and
> > the header to apr_sdbm. I'll go put a line into the STATUS file for voting
> > input.
> 
> This shouldn't require a vote.  What we have now is broken, and we are in
> commit then review mode.

Require? No... probably not. Considerate? Yes :-)

For changes that revamp existing APIs, I prefer to ask. Not always,
unfortunately, but when I think about it, I like to.

In this case, somebody may have an alternate opinion on what to do. For
example, Bill's initial suggestion was to simply hide SDBM altogether and
make people use apr_dbm_* to access it. I'd prefer to expose SDBM since we
have the darn thing, and then make apr_dbm separately available for people
that don't have a specific requirement on what DBM gets used.

Cheers,
-g

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

Mime
View raw message