httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: ap_ vs apr_ revisited.
Date Thu, 20 May 1999 05:49:05 GMT
On Wed, 19 May 1999, Dan Kegel wrote:

> Greg Stein wrote:
> > Ryan said something about porters not being able to discriminate what
> > needs to be ported from what is generic. That is a bunk reason. The
> > directory structure makes it quite clear what is platform specific vs.
> > generic. Prefixes will not alter anything there.
> Well... it seems to me that anyone reading source code rather
> than looking at directories will have to stop and scratch his/her
> head to figure out which side of the tracks any particular function
> is on.  If I were writing it, I'd certainly use a different prefix.
> Linus' viewpoint on these matters has been "The most elegant / practical
> code wins", even if it means plugin (driver) writers have to adapt.
> It's served him well.  It'll probably be ok for Apache, too.

Linus is not a democracy :) 

I say these comments with tounge-in-cheek.  It's really easy to get riled
up over cosmetic differences -- it's easy to construct a thousand examples
either way.  I'm guilty of doing it myself.  But what's not easy is
actually writing the code... and I personally find that when my
confidence/pride has been whittled down by a discussion like this, then I
falter while coding, never sure if I'm making the right choice. 

If choosing between ap_ and apr_ is the biggest problem we have facing us,
then we're pretty well off. 

If choosing between a context-in-a-pool or a pool-in-a-context is the
biggest problem we have facing us, then we're pretty well off. 

When really, there's really not much in favour of either solution... and
we can recover from a mistake in either direction.

At some point you need to give someone the creative freedom to engineer a
solution.  The way we use our voting process here does not give anyone the
freedom to engineer a solution.  The vote should be: 

[x] I think Ryan should be the design *lead* for APR
[ ] I want Brian to create
    so we can properly give tribute to this dilemma

Maybe that's just me though. 

Then if Ryan feels that he wants us to rename lots of code in our modules,
and everyone else's modules, that's his choice.  He can deal with the
fallout -- he's made his stand.  He's committing to write the code (he's
started already).  If nobody supported Ryan's position then we'd have to
reconsider if Ryan should be the design lead, but some people do support
Ryan's position.

Call me crazy!  (You will anyhow.)  But a business wouldn't survive if
every decision had to be voted on by all the employees.  By way of
comparison -- if we were a multiprocessor system, and someone profiled us,
they'd see us spending all our time in one spinlock waiting for some other
processor to finish up what it's doing... we're a redundant system, but we
don't perform very well, and we certainly don't scale. 

A year and a half ago (two and a half years ago?  I forget) I cried for
the freedom to commit code before having it reviewed, and I really think
it helped us.  Let Ryan commit. 

(er, go team! rah! rah! rah!) 


View raw message