There currently are four options listed in STATUS for changing
the time representation.  There are vetoes for two of them.  The
other are:

 2) Renaming the function to get rid of apr_time_t vs time_t confusion,
    but keep it ambigious and make no contract with the user about the
    units represented.

 3) Renaming the function to get rid of apr_time_t vs time_t confusion,
    and strongly identify the type as apr_busec_t or apr_butime_t, with
    an ongoing contract with users about the type's units.

Based on all our discussions of the past few days, I believe these
two options are identical in practice.

If the new time type is an abstract type, the common operations on
it will be:
    - Native C scalar + and - operations for time arithmetic
      (for performance and simplicity reasons)
    - Macros to extract seconds and microseconds

And if it's a transparent type, the common operations will be:
    - Native C scalar + and - operations for time arithmetic
    - Macros to extract seconds and microseconds (to spare application
      programmers the complexity of doing the shifts themselves)

I.e., no matter which option we use, I anticipate that the
code surrounding these types will look exactly the same.

The only major difference remaining seems to be the naming:
apr_utime_t (and interval variants thereof) vs apr_time_busec_t
(and interval variants thereof).

Can we come to an agreement on one of these names to bring
the issue to a close?

Thanks,
--Brian


Reply via email to