updated my votes on apr_table_t, added some explanatory notes

git-svn-id: http://svn.apache.org/repos/asf/apr/apr/trunk@63635 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 13 insertions, 2 deletions

diff --git a/STATUS b/STATUS
index fd6bd17d2..17db50eec 100644
--- a/STATUS
+++ b/STATUS
@@ -1,5 +1,5 @@
 APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:			-*-text-*-
-Last modified at [$Date: 2002/07/12 00:53:43 $]
+Last modified at [$Date: 2002/07/12 01:00:12 $]
 
 Release:
 
@@ -79,6 +79,7 @@ CURRENT VOTES:
          units represented.  Needs a better suggestion than apr_timeval_t.
          +1: aaron
          +1: jwoolley
+	 +1: brianp
          -0: wrowe, jerenkrantz, striker
          -0.5: rbb
 
@@ -89,13 +90,23 @@ CURRENT VOTES:
          +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.]
 
         [fielding: That's nonsense. What does overflow mean?  What are you