apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject RE: APRUTIL prefix
Date Wed, 06 Dec 2000 00:47:10 GMT
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
-------------------------------------------------------------------------------



Mime
View raw message