apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: more notes on the apr_time_t issue
Date Sat, 13 Jul 2002 17:32:11 GMT
At 11:35 AM 7/13/2002, Ryan Bloom wrote:
> > From: Aaron Bannert [mailto:aaron@clove.org]
> >
> > On Sat, Jul 13, 2002 at 09:16:17AM -0700, Ryan Bloom wrote:
> > > I really hate where our time implementation is going.  It used to be
> > > VERY simple, and easy to modify and use.  From looking at this
> > > conversation, it sounds like we are about to go to a VERY complex
> > > implementation that is hard to modify and use.  :-(
> >
> > Agreed that complexity is bad. I don't think we need more than one
> > system of time in APR*.
>
>We need two, one for standard time, and one for intervals, which are
>rooted at an arbitrary point in time.  However, even with just one
>implementation, the ideas being thrown about now are too complex.

Ryan... quit confusing the concept of one 'System of Time' (busec or
whatnot) with two or more C typedefs.

The system of time will be constant.  There will be one unanchored
type to represent intervals, deltas, diffs and spans.  These could become
more than one type in the future for clarity, but they will remain identities.

The one anchored timedef is also an identity of the first typedef, only
it is an absolute expression of a calendar time relative to epoch 1/1/1970.
It's still the same interval type, with a different name to signify that it 
is a
calendar time.

So Aaron is correct.  One 'System of Time' for APR.

>A big reason that they are too complex, is that rather than come up with
>a simple design, we are all afraid of the damned vetos that are being
>thrown about.  This whole conversation should just start over, with no
>vetos, and no emotions.  Vetos should be a last resort, but we don't use
>them as a last resort, we use them as a way to shape where people go
>with their ideas.

Because you haven't won the day?  Sorry, but the manner in which you
jumped into the conversation has left several folks with that impression.
Toss the vote so you can reargue and win your position?  That's how
that sort of statement comes across.  Of course the vote was clarified
for our audience when DReid asked us to stop and explain this whole
mess.  Several more people joined in the debate after Aaron's and my
big-picture backgrounders.  But the process continues, and it will
come to a conclusion.

Nobody is afraid of vetoes.  The most polar extremes lost [keeping the
current type, and changing the representation to POSIX time.]  Both
have two recorded vetoes.  The only veto folks objected to was a veto
of two year old design decisions that the voter hadn't commented to for
that substantial length of time; those designed decisions had been voted
and carried very early in the development process by the procedures of
the httpd-dev project.

This all leaves us at two plausible answers, rename the time types with
somewhat more generic identifiers, such as apr_utime_t, or change them
to something more specific, such as apr_time_busec_t.  Either way we
help our coders, not hurt them; legibility and performance both win.
It will be frustrating for porters and other current users of the code, but
it will give them pause [hopefully] long enough to check for invalid
assumptions in their code, and use the most optimal macros for their
specific code.

>Everytime a veto is thrown out, the development gets more
>confrontational.  What I hate most about this, is that I am a big reason
>that the damned vetos are as common as they are.

Yes, ASF development in general is confrontational.  We had questioned
some time ago why few Asians participate in the ASF, especially on the
httpd side of things ... at some deep level this is probably a good bit
of that reason.  Our process and approach goes against most cultural
norms, except principally in Europe and the Americas.  "Debate" is a
very European tradition.

The bigger issue in every debate are the personal attacks, rather than
attacks against code and reasoning.  That's when they turns repulsive.

To your second observation; probably.

Bill



Mime
View raw message