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
