apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@apache.org>
Subject Re: cvs commit: apr STATUS
Date Fri, 12 Jul 2002 07:57:48 GMT
>> Irrelevant.  If you want httpd to use APR, then it had better not make
>> httpd
>> worse for no good reason.  If there is a reason, then I want it 
>> documented
>> in the code.  If not, if it is just the whim of some folks using APR, 
>> then
>> I will fork the httpd project away from APR.
> Roy, isn't this a bit of a big fly swatter?  If you want to add an extra
> vote, the "royal veto" or anything, just say so.  This discussion is so
> growing out of proportions, it isn't funny anymore.

It isn't supposed to be funny.  I want to know why APR folks seem to think
that other applications of APR are as important, or even remotely as 
as the performance of httpd.  I want to know because all of the decisions
that have been made in the name of other application's "needs" have turned
out to be costly mistakes that we've had to revisit later, only to find out
that the other applications would have performed better anyway if we had
simply focused on what we KNOW is needed instead of inventing a whole new
can of worms.

> What's basically is happening is that we are growing towards two camps
> vetoing eachother.  Who's going to win?  The camp that rolls out the
> biggest gun?

I argued against this design from the very beginning.  I will not
include APR in my future projects if it is not going to be designed for the
needs of httpd, first and foremost, because that is what makes it a
worthwhile portability library.  I won't bother to veto the code in APR.

If you don't like that, then find a good reason why I should accept
lower performance code.  I am willing to buy trade-offs when they are
justified and code-complete.

>>  Nobody else has to follow the
>> redesign, but then at least I'll be satisfied in trying.  With the
>> binary microseconds change we have finally tackled the performance
>> concern to at least a level of reasonable trade-off, albeit undocumented.
>> Now we just need to solve the problem of all of the inconsistent code
>> due to people assuming (or never fixing) apr_time_t == time_t.
> I thought we were using opaque types all over the place to avoid people
> assuming anything.  We aren't mapping standard types (like time_t) to
> apr types, because that would be a silly effort. Introducing types in
> our namespace that are already portable, that is.

All of the apr_*_t types do exactly that.  I think you've been spending
far too much time in IRC.  Don't you guys know that synchronous 
degrades independent thought?

> I'm sorry, but I feel that if people want to code against APR, they
> should be aware of the API (reading the docs, looking at samples, etc),
> not just assume things.  Right now, our API is pretty intuitive; if I
> want to work with files I need an apr_file_t type, if I want something
> with time I need apr_time_t.  I'm kind of sad that we are moving away
> from that with this.

The code I was talking about came from httpd, pre-dated APR, and was
converted by our own committers.  And yet we still had many cases where
our own code wasn't consistent.  We still do.  The cause should be obvious.

> [...]
>>>     3. Is a veto of long existing code within APR allowed by protocol?
>> If there is a good reason, yes.
> So no code is safe?  It will be a pain to dig through the archives for
> previous votes on issues to see if there were vetos back in the old
> days that might conflict with newly raised vetos.  Very nasty.

Why do you need to dig through archives?  I'm not talking about vetoing
APR -- I've been talking about restoring the original httpd code that
implemented time faster, more efficiently, and with fewer inconsistencies
than the APR routines.

Somebody around here has to stand up and be a pain in the ass.  RST and
Dean are long gone, so that leaves me, at least until I get too busy
to think again.  I need to start working on a new server architecture
to support a new protocol, which means I need to choose which code to
reuse and which to rewrite.  While I'm figuring that out, I am uncovering
all of the design warts that haven't been fixed yet.


View raw message