You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/12/11 17:13:11 UTC
Showstoppers: Alpha 9
Ok,
two showstoppers exist for A9, in my (convoluted) mind;
1. is sdbm an -internally- packaged function, as is mm? (my 2c says yes)
If so, it has no business being distributed in httpd-2.0/include/apr-util,
since we certainly wouldn't distribute mm.h either. Same goes with
apu_config.h and apu_private.h. This means they don't belong in
apr-util/include either.
2. aprs are driving me nuts. Either we use src/ folders around the sources,
or we don't. Consistency is all I'm asking.
I'll fix either if we agree on how, but I would end up breaking the build.
Perhaps someone on Unix/libtool could do so, and I'll clean up the win32 asap.
Bill
RE: Showstoppers: Alpha 9
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I'm +1 on everything below ... including adding src/ to apr since neither
Ryan or I feel real strongly about it. Either way, with or without src/,
we should be able to pick-n-choose our packaging, and either way we will
stumble somewhere. Let's move forward, and thanks for the offer to clean
up those issues, I'll be sure win32 builds again :-)
> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, December 11, 2000 3:45 PM
> To: new-httpd@apache.org
> Cc: apr@dev.apache.org
> Subject: Re: Showstoppers: Alpha 9
>
>
> Does nobody read the STATUS file? Didn't I put all this in
> there and state
> that it would get cleared up by tonite for our release tomorrow?
>
> ... ah well.
>
> On Mon, Dec 11, 2000 at 10:13:11AM -0600, William A. Rowe, Jr. wrote:
> > Ok,
> >
> > two showstoppers exist for A9, in my (convoluted) mind;
> >
> > 1. is sdbm an -internally- packaged function, as is mm?
> (my 2c says yes)
>
> Nope. It will be exposed as apr_sdbm_*.
>
> Today, users can program directly to GDBM, DB3, whatever. By
> exposing it, we
> will also allow people to program directly to SDBM.
>
> However, I would think that most people don't care about the
> specific DBM
> backend and will just use apr_dbm_ functions. But when they
> *do* care, then
> it makes sense for us to let them.
>
> > If so, it has no business being distributed in
> httpd-2.0/include/apr-util,
>
> It will be named apr_sdbm.h.
>
> > since we certainly wouldn't distribute mm.h either.
> Same goes with
> > apu_config.h and apu_private.h. This means they don't belong in
> > apr-util/include either.
>
> Yes, apu_private.h and apu_config.h will move to include/private/.
>
> > 2. aprs are driving me nuts. Either we use src/ folders
> around the sources,
> > or we don't. Consistency is all I'm asking.
>
> +1 on src/ in the APRs. It scales to larger feature sets than
> when you omit
> it. My APR directory has 21 subdirs, which I find excessive.
> APRUTIL could
> easily grow to that size.
>
> > I'll fix either if we agree on how, but I would end up
> breaking the build.
> > Perhaps someone on Unix/libtool could do so, and I'll clean
> up the win32 asap.
>
> No problem. I was already planning to do the decided-upon
> items. The use of
> src/ within APR hasn't reached consensus in my mind, though.
>
> I would like to see more opinions on the src/ thing than
> myself, OtherBill,
> and Ryan. We should not proceed on *any* course of action
> without that. I
> suspect we will not have it resolved by tomorrow. I'm going
> to work on a
> bunch of the items for the release, but we should do
> something to get a
> write-up of the src-vs-not alternatives and get some more input.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
RE: Showstoppers: Alpha 9
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I'm +1 on everything below ... including adding src/ to apr since neither
Ryan or I feel real strongly about it. Either way, with or without src/,
we should be able to pick-n-choose our packaging, and either way we will
stumble somewhere. Let's move forward, and thanks for the offer to clean
up those issues, I'll be sure win32 builds again :-)
> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, December 11, 2000 3:45 PM
> To: new-httpd@apache.org
> Cc: apr@dev.apache.org
> Subject: Re: Showstoppers: Alpha 9
>
>
> Does nobody read the STATUS file? Didn't I put all this in
> there and state
> that it would get cleared up by tonite for our release tomorrow?
>
> ... ah well.
>
> On Mon, Dec 11, 2000 at 10:13:11AM -0600, William A. Rowe, Jr. wrote:
> > Ok,
> >
> > two showstoppers exist for A9, in my (convoluted) mind;
> >
> > 1. is sdbm an -internally- packaged function, as is mm?
> (my 2c says yes)
>
> Nope. It will be exposed as apr_sdbm_*.
>
> Today, users can program directly to GDBM, DB3, whatever. By
> exposing it, we
> will also allow people to program directly to SDBM.
>
> However, I would think that most people don't care about the
> specific DBM
> backend and will just use apr_dbm_ functions. But when they
> *do* care, then
> it makes sense for us to let them.
>
> > If so, it has no business being distributed in
> httpd-2.0/include/apr-util,
>
> It will be named apr_sdbm.h.
>
> > since we certainly wouldn't distribute mm.h either.
> Same goes with
> > apu_config.h and apu_private.h. This means they don't belong in
> > apr-util/include either.
>
> Yes, apu_private.h and apu_config.h will move to include/private/.
>
> > 2. aprs are driving me nuts. Either we use src/ folders
> around the sources,
> > or we don't. Consistency is all I'm asking.
>
> +1 on src/ in the APRs. It scales to larger feature sets than
> when you omit
> it. My APR directory has 21 subdirs, which I find excessive.
> APRUTIL could
> easily grow to that size.
>
> > I'll fix either if we agree on how, but I would end up
> breaking the build.
> > Perhaps someone on Unix/libtool could do so, and I'll clean
> up the win32 asap.
>
> No problem. I was already planning to do the decided-upon
> items. The use of
> src/ within APR hasn't reached consensus in my mind, though.
>
> I would like to see more opinions on the src/ thing than
> myself, OtherBill,
> and Ryan. We should not proceed on *any* course of action
> without that. I
> suspect we will not have it resolved by tomorrow. I'm going
> to work on a
> bunch of the items for the release, but we should do
> something to get a
> write-up of the src-vs-not alternatives and get some more input.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
Re: Showstoppers: Alpha 9
Posted by Greg Stein <gs...@lyra.org>.
Does nobody read the STATUS file? Didn't I put all this in there and state
that it would get cleared up by tonite for our release tomorrow?
... ah well.
On Mon, Dec 11, 2000 at 10:13:11AM -0600, William A. Rowe, Jr. wrote:
> Ok,
>
> two showstoppers exist for A9, in my (convoluted) mind;
>
> 1. is sdbm an -internally- packaged function, as is mm? (my 2c says yes)
Nope. It will be exposed as apr_sdbm_*.
Today, users can program directly to GDBM, DB3, whatever. By exposing it, we
will also allow people to program directly to SDBM.
However, I would think that most people don't care about the specific DBM
backend and will just use apr_dbm_ functions. But when they *do* care, then
it makes sense for us to let them.
> If so, it has no business being distributed in httpd-2.0/include/apr-util,
It will be named apr_sdbm.h.
> since we certainly wouldn't distribute mm.h either. Same goes with
> apu_config.h and apu_private.h. This means they don't belong in
> apr-util/include either.
Yes, apu_private.h and apu_config.h will move to include/private/.
> 2. aprs are driving me nuts. Either we use src/ folders around the sources,
> or we don't. Consistency is all I'm asking.
+1 on src/ in the APRs. It scales to larger feature sets than when you omit
it. My APR directory has 21 subdirs, which I find excessive. APRUTIL could
easily grow to that size.
> I'll fix either if we agree on how, but I would end up breaking the build.
> Perhaps someone on Unix/libtool could do so, and I'll clean up the win32 asap.
No problem. I was already planning to do the decided-upon items. The use of
src/ within APR hasn't reached consensus in my mind, though.
I would like to see more opinions on the src/ thing than myself, OtherBill,
and Ryan. We should not proceed on *any* course of action without that. I
suspect we will not have it resolved by tomorrow. I'm going to work on a
bunch of the items for the release, but we should do something to get a
write-up of the src-vs-not alternatives and get some more input.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Showstoppers: Alpha 9
Posted by rb...@covalent.net.
Replying to the correct address now.
On Mon, 11 Dec 2000 rbb@covalent.net wrote:
>
> > 1. is sdbm an -internally- packaged function, as is mm? (my 2c says yes)
> > If so, it has no business being distributed in httpd-2.0/include/apr-util,
> > since we certainly wouldn't distribute mm.h either. Same goes with
> > apu_config.h and apu_private.h. This means they don't belong in
> > apr-util/include either.
>
> I have to agree with OtherBill here. SDBM should be an internal
> package. We have already admitted that it is only to be used as a
> last-resort package.
>
> > 2. aprs are driving me nuts. Either we use src/ folders around the sources,
> > or we don't. Consistency is all I'm asking.
>
> Personally, -0 for using src.
>
> > I'll fix either if we agree on how, but I would end up breaking the build.
> > Perhaps someone on Unix/libtool could do so, and I'll clean up the win32 asap.
>
> If we agree on any of this, I'll fix the Unix builds.
>
> Ryan
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Showstoppers: Alpha 9
Posted by rb...@covalent.net.
Replying to the correct address now.
On Mon, 11 Dec 2000 rbb@covalent.net wrote:
>
> > 1. is sdbm an -internally- packaged function, as is mm? (my 2c says yes)
> > If so, it has no business being distributed in httpd-2.0/include/apr-util,
> > since we certainly wouldn't distribute mm.h either. Same goes with
> > apu_config.h and apu_private.h. This means they don't belong in
> > apr-util/include either.
>
> I have to agree with OtherBill here. SDBM should be an internal
> package. We have already admitted that it is only to be used as a
> last-resort package.
>
> > 2. aprs are driving me nuts. Either we use src/ folders around the sources,
> > or we don't. Consistency is all I'm asking.
>
> Personally, -0 for using src.
>
> > I'll fix either if we agree on how, but I would end up breaking the build.
> > Perhaps someone on Unix/libtool could do so, and I'll clean up the win32 asap.
>
> If we agree on any of this, I'll fix the Unix builds.
>
> Ryan
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Showstoppers: Alpha 9
Posted by rb...@covalent.net.
> 1. is sdbm an -internally- packaged function, as is mm? (my 2c says yes)
> If so, it has no business being distributed in httpd-2.0/include/apr-util,
> since we certainly wouldn't distribute mm.h either. Same goes with
> apu_config.h and apu_private.h. This means they don't belong in
> apr-util/include either.
I have to agree with OtherBill here. SDBM should be an internal
package. We have already admitted that it is only to be used as a
last-resort package.
> 2. aprs are driving me nuts. Either we use src/ folders around the sources,
> or we don't. Consistency is all I'm asking.
Personally, -0 for using src.
> I'll fix either if we agree on how, but I would end up breaking the build.
> Perhaps someone on Unix/libtool could do so, and I'll clean up the win32 asap.
If we agree on any of this, I'll fix the Unix builds.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------