Date: Tue, 4 May 1999 08:09:25 -0400 (EDT)
From: Ryan Bloom <rbb@raleigh.ibm.com>
To: new-httpd@apache.org
Subject: Re: apr_ v.s. ap_
In-Reply-To: <372ED995.2C2685FA@lyra.org>
Message-ID: <Pine.A41.4.05.9905040751180.15674-100000@webdev7.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


How's this for an argument then.  Apahce and APR are different entities.
They are currently coupled together, because APR is being developed with
Apache in mind.  I would hope, that APR will not stop being developed when
it has everything Apache needs.

The goal of the ap_ and apr_ prefix is to avoid namespace collision.
Currently, because they are being developed together, that namespace
collision isn't happening.  What happens in the future.  I have no clue
where APR could be in a year, does anybody?  Are we willing to say that
there will NEVER be any namespace collision between Apache and APR?  That
seems like a very strong statement.

ap_ is the accepted apache way to name things.  apr_ is currently the
accepted apr way to name things.  I just don't see a good reason to
collapse them into one naming convention.  I would rather use two
different naming conventions, one for apache supplied functions and one
for apr supplied functions, than take the cahnce that at some point in the
future we have to rename all of the functions from one of the two
projects.

Apache 2.0 seems like a reasonable place to make the change from using
apr_ for platform independant functions that have NOTHING to do with a
web server.  Isn't that the key to this whole thing?  Any ap_ function
should be used in the running of a WEBSERVER, and a webserver only.  Any
apr_ function is a part of a library that is cross platform and is ready
to be plugged into ANY project that needs it.

To me, this division makes sense.  The arguments below probably weren't
clear enough, because I was reponding to a statement that sounded to me
like "Lets not make our users change any of their code", and I was just
pointing out that their code is going to change, regardless of whether we
use ap_ or apr_ inside the apr library.

The change from ap_ ro apr_ is not a gratiutous change.  It is a reflect
of us using a completely different library for some of our none webserver
routines.

One more argument here.  Let's say in the future, we discover that apr
isn't being developed any more, and there are features we need.  But, NSPR
is still being developed, and it is becoming the de facto standard for
cross-paltform development.  If Apache decides to use NSPR for it's next
release, will we also argue with the Mozilla people that they need to
change their names to begin with ap_?  No, of course not, because it is a
separate project.  It seems to me, ANYTHING in the new library should have
a completely different namespace, because it is a completely different
project.

The changes themselves aren't too hard to make.  Especially since the code
hasn't gone out the door yet.  I just think it is a mistake to tie APR to
Apache too closely.

Ryan

> You keep using that argument, and I keep thinking it is bogus.
> 
> Yes, things will change, but why throw EVEN MORE changes at the person?
> Geez. Should we also rename the request_rec fields? Hey, why not... they
> have to recode their module anyhow. Oh... how about the #defines such as
> HTTP_METHOD_NOT_ALLOWED? Those should start with AP_, right? Let's
> change those, too! And OK, DONE, and DECLINED while we're at it!
> 
> Of course those are silly, extreme suggestions, but it is an example of
> your logic taken to the next step.
> 
> While people will need to change certain things about their modules, we
> should not gratuitously heap another bulk of changes on them just
> because we can.
> 
> Cheers,
> -g
> 
> --
> Greg Stein, http://www.lyra.org/
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.