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