You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/12/08 16:03:59 UTC
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
> From: gstein@locus.apache.org [mailto:gstein@locus.apache.org]
> Sent: Friday, December 08, 2000 12:45 AM
>
> gstein 00/12/07 22:44:55
>
> Removed: 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
> Log:
> 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.
I'll work up the patch _now_.
Bill
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
Posted by rb...@covalent.net.
> > > > > 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.
I wasn't actually thinking of renaming the entry points right now. Right
now, I just want to get the header file renamed, because it is invalid to
install it as it is now. The entry point change can wait a few days, but
if we are going to release an Apache alpha on Monday, the file name needs
to change before we release the alpha.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
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
Posted by Greg Stein <gs...@lyra.org>.
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/
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Friday, December 08, 2000 5:14 PM
> > 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.
apr_ prefixes get a +1 here :-)
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
Posted by rb...@covalent.net.
> > > > > 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
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
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 08, 2000 at 02:28:27PM -0800, rbb@covalent.net wrote:
>
> > > > Removed: 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
> > > > Log:
> > > > 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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
Posted by rb...@covalent.net.
> > > Removed: 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
> > > Log:
> > > 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
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
Posted by rb...@covalent.net.
> > > Removed: 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
> > > Log:
> > > 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
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
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 08, 2000 at 09:03:59AM -0600, William A. Rowe, Jr. wrote:
> > From: gstein@locus.apache.org [mailto:gstein@locus.apache.org]
> > Sent: Friday, December 08, 2000 12:45 AM
> >
> > gstein 00/12/07 22:44:55
> >
> > Removed: 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
> > Log:
> > 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 08, 2000 at 09:03:59AM -0600, William A. Rowe, Jr. wrote:
> > From: gstein@locus.apache.org [mailto:gstein@locus.apache.org]
> > Sent: Friday, December 08, 2000 12:45 AM
> >
> > gstein 00/12/07 22:44:55
> >
> > Removed: 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
> > Log:
> > 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/