httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject Re: apr_ v.s. ap_
Date Tue, 04 May 1999 13:32:50 GMT

Ryan Bloom <> writes:

> 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.

No argument here, but if APR where to wander away from serving Apache's
needs Apache would fork and maintain it's own version.  APR would, for
the forseeable future, bend over backward to avoid that happening.

> 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?

In what senario would APR introduce a name that collides with the
names used by its principle customer and sponser?  That would be

Your buying very expensive insurance today against an unlikely event
in the future.  

>  Are we willing to say that
> there will NEVER be any namespace collision between Apache and APR?  That
> seems like a very strong statement.

That is what I'm saying, and it isn't a strong statement it's a statement
about how these two projects are peas in the same pod, friends, buddies.

> 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.  

The reason is to prevent unnecessary change in Apache.

> 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.

I'd rather not, so we vote.

> 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.

That is the current design.  At what cost?

> 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.

Is there any senario where you'd act to limit the costs inflicted on
users by these changes?  Should the sanctity of the APR design ever
suffer in exchange for lower those costs?  Do you have any concept
of the magnitude of these costs?

> 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.

It's not gratiutious, it's cruel.  If you had paying customers they
would just say "no way" and that would be that.

> 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.

This class of argument just doesn't work for me.  These are the "suffer
today for possible good tommorrow" arguments.  The suffering today
is absolutely certian, the chance of tommorrow's benifit is almost zero.

> 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.

That it "hasn't gone out the door yet" makes if anything worse.  It
only assures that a large community of people who will have to bear
the cost are not here to speak up.

> Ryan

 - ben

View raw message