You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Stein <gs...@lyra.org> on 2000/12/02 23:34:05 UTC
APRUTIL prefix
After I checked in the stuff last night, I realized that "apu_config.h" was
probably using the "wrong" prefix.
Does anybody have a good idea for what prefix we *do* want to use?
Maybe "aul" for "Apache Utility Library"? Continue with "apu" for "APache
Utilities [library]"?
Others?
Note that Apache 2.0 will need to include a header in src/include/ which
maps the old names it knows/uses for the functions/type over to the new
names. (I don't think that renaming goes in aprutil itself since the naming
problem is just for Apache)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: APRUTIL prefix
Posted by rb...@covalent.net.
On Tue, 5 Dec 2000, William A. Rowe, Jr. wrote:
> > From: Roy T. Fielding [mailto:fielding@ebuilt.com]
> >
> > I am still categorically opposed to any prefix other than ap_ for
> > any symbols in any C library that is based on code developed by
> > the Apache projects. Including apr and apr-util, though I don't
> > consider myself to have voting rights on that code. It is, and
> > always has been, nothing but a pain in the ass.
>
> If we are 100% convinced that we will never have public symbol
> overlap (ap_foo residing in httpd-2.0/server and apr/misc) then I'd
> agree with your position. Same logic we are using to justify the
> identical symbols between apr and aprutil. It's easier for us to
> eyeball which package they come from as is, but I don't know that
> it benefits the wider developer world.
>
> Export symbols are an exception into and of themselves (but could
> be AP_x_DECLARE to match the namespace.)
The reason for changing the APR prefix, was that those functions were
useful completely separate from Apache and in Apache 1.3 inside of
modules. Since a good portion of the functions that were moved into APR
now required different arguments and different types, this was impossible
to do if they kept the same name.
As for apr-util, I am becoming more and more convinced that most of what
is in apr-util is not useful in a separate Apache 1.3 module, and (perhaps
more importantly), those functions have not had types and/or prototypes
changed since they were moved out of Apache. I am perfectly happy keeping
with the ap_ prefix.
I do have a problem with what is moving into apr-utils however. What ties
all of this code together? What is the underlying problem that apr-utils
is trying to solve? At least with APR, we always knew the code had to be
as portable as possible, and preferably it would help portability in
general. So far in apr-util, we have dbm wrappers (which should have just
been taken from PHP instead of re-doing their work), buckets, hooks
(completely not useful outside of Apache AFAICS), encoding, and crypt
routines. I don't see a common thread here other than the fact that
Apache needs each of these things.
Why would I download and use apr-utils instead of downloading apr-utils,
and taking the code I need? I dislike having a project whose definition
is "This is a kitchen sink of useful functions."
Just my $0.02
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: APRUTIL prefix
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Roy T. Fielding [mailto:fielding@ebuilt.com]
> Sent: Tuesday, December 05, 2000 3:44 PM
>
> I am still categorically opposed to any prefix other than ap_ for
> any symbols in any C library that is based on code developed by
> the Apache projects. Including apr and apr-util, though I don't
> consider myself to have voting rights on that code. It is, and
> always has been, nothing but a pain in the ass.
>
> Just wanted to make my opinion clear.
If we are 100% convinced that we will never have public symbol
overlap (ap_foo residing in httpd-2.0/server and apr/misc) then I'd
agree with your position. Same logic we are using to justify the
identical symbols between apr and aprutil. It's easier for us to
eyeball which package they come from as is, but I don't know that
it benefits the wider developer world.
Export symbols are an exception into and of themselves (but could
be AP_x_DECLARE to match the namespace.)
Re: APRUTIL prefix
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
I am still categorically opposed to any prefix other than ap_ for
any symbols in any C library that is based on code developed by
the Apache projects. Including apr and apr-util, though I don't
consider myself to have voting rights on that code. It is, and
always has been, nothing but a pain in the ass.
Just wanted to make my opinion clear.
....Roy
Re: APRUTIL prefix
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Dec 02, 2000 at 02:58:15PM -0800, rbb@covalent.net wrote:
> > > > After I checked in the stuff last night, I realized that "apu_config.h" was
> > > > probably using the "wrong" prefix.
> > >
> > > I would suggest we just use APR. This is the APR utility library, and it
> > > makes sense in my mind to use the same prefix.
> >
> > Hmm. We would then need to coordinate across the two libraries. A bit of a
> > possible headache.
>
> But the whole point of apr-utils is that it doesn't have the same
> functions as APR. If there is ever a time that the two libraries have
> this problem, then something is already horribly wrong.
Excellent point!
> > > I would suggest doing what APR does, which is to put the compat header in
> > > the library's include directory.
> >
> > Well, I think that was a bit different. There were potentially other users
> > of the APR functions by that point. By including that header in APR, it was
> > saying "we changed our names, but will provide this header for you."
> >
> > APRUTIL *starts* with a new set of names, and Apache is the person who needs
> > to compensate.
> >
> > In other words, there are no APRUTIL users other than Apache that are
> > affected by the rename. Any third-party Apache modules will have the
> > "compat" header available via Apache.
>
> I disagree, as somebody who regularly takes functions from Apache and uses
> them in my own code, I am going to convert my projects to use apr-utils
> ASAP, which means either I need to duplicate the header file or change my
> code. I will change my code quickly, but others would probably choose to
> duplicate the header for a while. We solve this problem by putting the
> header with the library.
I guess this viewpoint could simply be described as "these functions have a
real history (which we also try to preserve in CVS), and we renamed them
during the incorporation into APRUTIL. For the benefit of historical users,
we will provide a compatibility header."
That said, I'm +0 on placing the header into aprutil itself.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: APRUTIL prefix
Posted by rb...@covalent.net.
> > > After I checked in the stuff last night, I realized that "apu_config.h" was
> > > probably using the "wrong" prefix.
> >
> > I would suggest we just use APR. This is the APR utility library, and it
> > makes sense in my mind to use the same prefix.
>
> Hmm. We would then need to coordinate across the two libraries. A bit of a
> possible headache.
But the whole point of apr-utils is that it doesn't have the same
functions as APR. If there is ever a time that the two libraries have
this problem, then something is already horribly wrong.
> > I would suggest doing what APR does, which is to put the compat header in
> > the library's include directory.
>
> Well, I think that was a bit different. There were potentially other users
> of the APR functions by that point. By including that header in APR, it was
> saying "we changed our names, but will provide this header for you."
>
> APRUTIL *starts* with a new set of names, and Apache is the person who needs
> to compensate.
>
> In other words, there are no APRUTIL users other than Apache that are
> affected by the rename. Any third-party Apache modules will have the
> "compat" header available via Apache.
I disagree, as somebody who regularly takes functions from Apache and uses
them in my own code, I am going to convert my projects to use apr-utils
ASAP, which means either I need to duplicate the header file or change my
code. I will change my code quickly, but others would probably choose to
duplicate the header for a while. We solve this problem by putting the
header with the library.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: APRUTIL prefix
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Dec 02, 2000 at 02:36:35PM -0800, rbb@covalent.net wrote:
>
> > After I checked in the stuff last night, I realized that "apu_config.h" was
> > probably using the "wrong" prefix.
>
> I would suggest we just use APR. This is the APR utility library, and it
> makes sense in my mind to use the same prefix.
Hmm. We would then need to coordinate across the two libraries. A bit of a
possible headache.
> > Note that Apache 2.0 will need to include a header in src/include/ which
> > maps the old names it knows/uses for the functions/type over to the new
> > names. (I don't think that renaming goes in aprutil itself since the naming
> > problem is just for Apache)
>
> I would suggest doing what APR does, which is to put the compat header in
> the library's include directory.
Well, I think that was a bit different. There were potentially other users
of the APR functions by that point. By including that header in APR, it was
saying "we changed our names, but will provide this header for you."
APRUTIL *starts* with a new set of names, and Apache is the person who needs
to compensate.
In other words, there are no APRUTIL users other than Apache that are
affected by the rename. Any third-party Apache modules will have the
"compat" header available via Apache.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: APRUTIL prefix
Posted by rb...@covalent.net.
> After I checked in the stuff last night, I realized that "apu_config.h" was
> probably using the "wrong" prefix.
I would suggest we just use APR. This is the APR utility library, and it
makes sense in my mind to use the same prefix.
> Note that Apache 2.0 will need to include a header in src/include/ which
> maps the old names it knows/uses for the functions/type over to the new
> names. (I don't think that renaming goes in aprutil itself since the naming
> problem is just for Apache)
I would suggest doing what APR does, which is to put the compat header in
the library's include directory.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------