You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@raleigh.ibm.com> on 1999/05/19 18:57:31 UTC
ap_ vs apr_ revisited.
I am posting this note to both new-httpd and apache-modules.
I was more than happy to leave this issue alone, but some things have
happened that make me question the desision made earlier. When we made
the last decision, we said we would re-visit the issue if a compelling
reason came up, I believe this is such an issue.
Early last week, I was talking to a group that will be porting Apache to
another platform. I explained the relationship between Apache and apr,
and the hope that the vast majority of OS specific code will be localized
in apr and kept out of Apache. I showed them some apr functions from
after the change to ap_. Their first question was "So if we see a
function with the prefix "ap_" that's an apr function, and it needs to be
ported?" At this point, I had to explain the decision, and I watch their
faces fall, as they realized they had to work to figure out which
functions belonged to which project. (Yes, most of the functions are
documented in the docs directory, but That doesn't mean all of them all,
and I am willing to bet in the future, the docs won't stay up to date.)
Because the porting issue was never brought up when we had our initial
vote about the prefix, I am asking for a second vote.
I would ask everybody who has an opinion to vote. This issue has
implications which effect all Apache developers. I will tally the votes
and report them on Monday morning. This gives everybody plenty of time
to vote on this issue.
If you voted the last time, please vote again so I don't have to dig
through archives for your vote last time.
I would like to see the prefix for apr functions to be:
[ ] ap_ [ ] apr_ [ ] I don't care.
Ryan
_______________________________________________________________________
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.
Re: ap_ vs apr_ revisited.
Posted by Frank Faubert <fr...@sane.com>.
> I would like to see the prefix for apr functions to be:
>
> [ ] ap_ [X] apr_ [ ] I don't care.
>
Re: ap_ vs apr_ revisited.
Posted by Dan Kegel <da...@alumni.caltech.edu>.
Ryan Bloom wrote:
> I would like to see the prefix for apr functions to be:
>
> [ ] ap_ [X] apr_ [ ] I don't care.
- Dan
Re: ap_ vs apr_ revisited.
Posted by David Reid <ab...@dial.pipex.com>.
Don't know if my vote counts...but here it is anyway!
> I would like to see the prefix for apr functions to be:
>
> [ ] ap_ [ X ] apr_ [ ] I don't care.
Re: ap_ vs apr_ revisited.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
I would like to see the prefix for apr functions to be:
[ ] ap_ [X] apr_ [ ] I don't care.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: ap_ vs apr_ revisited.
Posted by tv...@aventail.com.
Ryan Bloom <rb...@raleigh.ibm.com> writes:
> I would ask everybody who has an opinion to vote.
I've lots of opinions. :)
>
> I would like to see the prefix for apr functions to be:
>
> [ ] ap_ [X] apr_ [ ] I don't care.
-Tom
--
Tom Vaughan <tvaughan at aventail dot com>
Re: ap_ vs apr_ revisited.
Posted by Greg Stein <gs...@lyra.org>.
Ryan Bloom wrote:
> ...
> Early last week, I was talking to a group that will be porting Apache to
> another platform. I explained the relationship between Apache and apr,
> and the hope that the vast majority of OS specific code will be localized
> in apr and kept out of Apache. I showed them some apr functions from
> after the change to ap_. Their first question was "So if we see a
> function with the prefix "ap_" that's an apr function, and it needs to be
> ported?" At this point, I had to explain the decision, and I watch their
> faces fall, as they realized they had to work to figure out which
> functions belonged to which project. (Yes, most of the functions are
> documented in the docs directory, but That doesn't mean all of them all,
> and I am willing to bet in the future, the docs won't stay up to date.)
This is silly. All "apr" functions would be under src/lib/apr/. Just
port anything you find in there.
What is the problem with that? Port by location in the source tree, NOT
the name.
This is really silly to revisit... there is no "compelling reason".
>...
> I would like to see the prefix for apr functions to be:
>
> [X] ap_ [ ] apr_ [ ] I don't care.
My vote is only because I know a tally will still be taken. However, I
*protest* the need to vote in the first place.
-g
--
Greg Stein, http://www.lyra.org/
Re: ap_ vs apr_ revisited.
Posted by Ben Hyde <bh...@pobox.com>.
Ryan Bloom <rb...@raleigh.ibm.com> writes:
> > The function of APR is to provide a platform independent
> > threading framework for us. It is a proven fact that
> > this does not require forcing all modules to rewrite.
> > We proved that on the NT where we already have theading.
>
> NO! The function of APR is to provide a platform independant framework
> ...
Yes, we disagree about what APR ought to and must do to the
installed base don't we.
- ben
Re: ap_ vs apr_ revisited.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> The function of APR is to provide a platform independent
> threading framework for us. It is a proven fact that
> this does not require forcing all modules to rewrite.
> We proved that on the NT where we already have theading.
NO! The function of APR is to provide a platform independant framework
for us. Minor difference, but the fact is, APR is providing a lot more
than threading. File I/O, Network I/O, all the things that require
platforms like Windows to have different code paths than Unix. APR is a
way to get all of our platforms using the same path through the Apache
code.
This does require a re-write of modules. Module writers cannot use an int
for file's that Apache has any access to. Apache won't know how to deal
with an int as a file. Modules will have to use apr_file_t's. The port
to a threaded server (i.e.: Windows) is not a good analogy. A much better
analogy is a port to nspr. If you look at the modules in the nspr
repository, they have been re-written to take advantage of nspr. I don't
know if that was because they had to be, or because it was the easiest way
to make them cross-platform, but I would bet they had to be re-written.
No, this is a vote for do you want two different projects to be in the
same namespace.
Ryan
_______________________________________________________________________
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.
Re: ap_ vs apr_ revisited.
Posted by un...@riverstyx.net.
Well, there's not going to be much work in modifying the modules. It's
just a string substitution, as long as the actual parameters haven't
changed, in which case more needs to be done anyway. I bet it would take
two or three people a couple days to sift through all the modules and flip
over the simple modules at modules.apache.org.
---
tani hosokawa
river styx internet
On 19 May 1999, Ben Hyde wrote:
>
> This is a trick question isn't it?
>
> You asking.
>
> Do I like clean denotation in my names
> [ ] yes
> [ ] no.
>
> but your really asking:
>
> May I force unneeded module rewriting so APR can
> have it's own mnemonic.
> [ ] yes
> [ ] no
>
> The function of APR is to provide a platform independent
> threading framework for us. It is a proven fact that
> this does not require forcing all modules to rewrite.
> We proved that on the NT where we already have theading.
>
> This is a vote about:
> Do you want to reimplement all your modules or not
>
> - ben
>
Re: ap_ vs apr_ revisited.
Posted by Ben Hyde <bh...@pobox.com>.
This is a trick question isn't it?
You asking.
Do I like clean denotation in my names
[ ] yes
[ ] no.
but your really asking:
May I force unneeded module rewriting so APR can
have it's own mnemonic.
[ ] yes
[ ] no
The function of APR is to provide a platform independent
threading framework for us. It is a proven fact that
this does not require forcing all modules to rewrite.
We proved that on the NT where we already have theading.
This is a vote about:
Do you want to reimplement all your modules or not
- ben
RE: ap_ vs apr_ revisited.
Posted by Andrew Finkenstadt <an...@simutronics.com>.
I am on both mailing lists, following the issues. I'll vote once as an
Apache module person.
I would like to see the prefix for apr functions to be:
[ ] ap_ [X] apr_ [ ] I don't care.
Andy Finkenstadt
-----Original Message-----
From: Ryan Bloom [mailto:rbb@raleigh.ibm.com]
Sent: Wednesday, May 19, 1999 11:58 AM
To: new-httpd@apache.org
Cc: apache-modules@covalent.net
Subject: ap_ vs apr_ revisited.
I would ask everybody who has an opinion to vote. This issue has
implications which effect all Apache developers. I will tally the votes
and report them on Monday morning. This gives everybody plenty of time
to vote on this issue.
If you voted the last time, please vote again so I don't have to dig
through archives for your vote last time.
Re: ap_ vs apr_ revisited.
Posted by Dean Gaudet <dg...@arctic.org>.
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 ap-vs-apr-tastes-great-less-filling@apache.org
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!)
Dean
Re: ap_ vs apr_ revisited.
Posted by Dan Kegel <da...@alumni.caltech.edu>.
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.
- Dan
Re: ap_ vs apr_ revisited.
Posted by Greg Stein <gs...@lyra.org>.
On Wed, 19 May 1999, Dean Gaudet wrote:
> On Wed, 19 May 1999, Ryan Bloom wrote:
>
> > [ ] ap_ [ ] apr_ [ ] I don't care.
>
> [x] democracy is not an effective business strategy
>
> Dean
I agree. This is silliness. Are we just going to keep voting until Ryan
gets his way?
We went through this just a couple weeks ago. NOTHING HAS CHANGED. Why is
this happening yet again?
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.
The other arguments (e.g. "forcing people to rewrite" vs "they have to
anyway") are silly to re-iterate yet again. We went though those before
and those answers certainly have not changed.
I vote to stop this silliness, leave the current ap_ prefix, and continue
without these periodic voting requests.
Regards,
-g
--
Greg Stein, http://www.lyra.org/
Re: ap_ vs apr_ revisited.
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 19 May 1999, Ryan Bloom wrote:
> [ ] ap_ [ ] apr_ [ ] I don't care.
[x] democracy is not an effective business strategy
Dean
Re: ap_ vs apr_ revisited.
Posted by un...@riverstyx.net.
> [ ] ap_ [X] apr_ [ ] I don't care.
Re: ap_ vs apr_ revisited.
Posted by "Edward S. Marshall" <em...@xnet.com>.
On Wed, 19 May 1999, Ryan Bloom wrote:
> [ ] ap_ [X] apr_ [ ] I don't care.
--
-- Edward S. Marshall <em...@xnet.com> --- http://www.xnet.com/~emarshal/ --
Grant me the serenety to accept the things I cannot change, the courage to
change the things I cannot accept, and the wisdom to hide the bodies of the
people I had to kill because they pissed me off. [ Ancient Office Prayer ]
Re: ap_ vs apr_ revisited.
Posted by co...@tdiinc.com.
> I would ask everybody who has an opinion to vote. This issue has
> implications which effect all Apache developers. I will tally the votes
> and report them on Monday morning. This gives everybody plenty of time
> to vote on this issue.
> I would like to see the prefix for apr functions to be:
>
> [ ] ap_ [X] apr_ [ ] I don't care.
I think it would be better to have more prefixes ( like
apr_thread_, apr_io_, apr_mutex_)
More information in the function name -> easier to use the
function.
2 "categories" ( specified in method name ) are better than 1 category.
In C++ and java the class name helps a lot. A flat namespace may be harder
to use.
Costin
Re: ap_ vs apr_ revisited.
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
I would like to see the prefix for apr functions to be:
[ ] ap_ [ ] apr_ [X] I don't care.
-Rasmus
RE: ap_ vs apr_ revisited.
Posted by RobS <ro...@ipass.net>.
> [ ] ap_ [X] apr_ [ ] I don't care.
--robs