apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: cvs commit: apr STATUS
Date Fri, 12 Jul 2002 07:14:08 GMT
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: 12 July 2002 04:20

>>   I will say the very same thing Ryan did several weeks [months?] ago.
>> Where were you for the last two years?
> 
> Complaining about how fucked up the design decisions were for apr_time_t.
> Its in the archives.  People didn't want to deal with it before due to
> more pressing concerns.  2.0 is now out, so there are no more excuses.
> 
>>   The questions on the table in APR is;
>>
>>     1. are we the special interest of httpd alone?  Are we their 
>> sub-project?
> 
> 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.
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?

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

[...]
>>     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.
 
>>     4. What is an appropriate name?  This A. depends on
[kind of went into this above]

[...don't want to drag this on too long...]

Sander

PS.  All this over apr_time_t...

Mime
View raw message