brianp 2002/07/11 18:00:12
Modified: . STATUS
Log:
updated my votes on apr_table_t, added some explanatory notes
Revision Changes Path
1.151 +13 -2 apr/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apr/STATUS,v
retrieving revision 1.150
retrieving revision 1.151
diff -u -r1.150 -r1.151
--- STATUS 12 Jul 2002 00:53:43 -0000 1.150
+++ STATUS 12 Jul 2002 01:00:12 -0000 1.151
@@ -79,6 +79,7 @@
units represented. Needs a better suggestion than apr_timeval_t.
+1: aaron
+1: jwoolley
+ +1: brianp
-0: wrowe, jerenkrantz, striker
-0.5: rbb
@@ -89,12 +90,22 @@
+1: jwoolley
+0.5: wrowe
-0: striker, jerenkrantz
- -0.5: rbb
+ -0.5: rbb, brianp
[fielding: Is APR time guaranteed to be a scalar quantity? If so,
then we must include units as part of the definition of the
type in order to let developers make use of that quarantee.
In that case, the units should be in the type name [e.g., apr_busec]
+
+ [brianp: I think that apr_time_t is really a "struct with an
+ compact representation that we can pass around easily and
+ add/subtract efficiently," rather than a scalar. It's probably
+ worth noting that I look at it this way because it often is
+ populated from the struct timeval produced by gettimeofday().
+ Because I think of the scalar representation as an implementation
+ detail, rather than an feature of the time API, I'd prefer to
+ use a name that doesn't advertise the binary microseconds concept.
+ But I've changed my -1 on the binary microsecond name to a -0.5.]
[wrowe: deltas require NO definition of the scale.]
