Just to clarify the technical reason for vetoing the use of apr_time_t
with a new implementation. The reason I veto this is because I don't
want us to maintain binary compatibility while we're not maintaining
semantic compatibility. There are programs out there that use APR's
apr_time_t and will treat them as decimals. This will result in very
subtle timing bugs that will be *very* hard to track down. Since
we're coming up with a new interface (as well as a new implementation)
it needs to have a new name.

-aaron



On Thu, Jul 11, 2002 at 07:10:53PM -0000, [EMAIL PROTECTED] wrote:
> aaron       2002/07/11 12:10:53
> 
>   Modified:    .        STATUS
>   Log:
>   These two questions aren't orthogonal, so the votes don't all make sense.
>   But here are my votes anyway.
>   
>   Revision  Changes    Path
>   1.137     +4 -2      apr/STATUS
>   
>   Index: STATUS
>   ===================================================================
>   RCS file: /home/cvs/apr/STATUS,v
>   retrieving revision 1.136
>   retrieving revision 1.137
>   diff -u -r1.136 -r1.137
>   --- STATUS  11 Jul 2002 19:03:25 -0000      1.136
>   +++ STATUS  11 Jul 2002 19:10:53 -0000      1.137
>   @@ -66,9 +66,11 @@
>             system types, or map to system units.
>             +1: rbb, wrowe, jerenkrantz
>             +0: brianp
>   +         -1: aaron [veto for reusing the apr_time_t identifier for a new 
> use.
>   +                    I'm ok with apr_timeval_t.]
>          2) Renaming the function to get rid of apr_time_t vs time_t 
> confusion,
>             which wrowe suggests apr_butime_t [binary microtime].
>   -         +1: fielding
>   +         +1: fielding, aaron
>             -0: wrowe, jerenkrantz
>             -0.5: rbb
>             -1: brianp [-1 for the apr_butime_t name specifically: let's
>   
>   
>   

Reply via email to