next steps for changing apr_time_t?

[Brian Pane <bp...@pacbell.net>]

Based on the votes in STATUS, there's a consensus in favor of changing
from the current apr_time_t implementation to a binary microseconds
implementation.  Meanwhile, I've removed most of the dependencies on
the old design from the httpd-2.0 code.

A couple of important questions remain, though:

    How much will this impact other APR-based apps (SVN, Flood, etc),
    and is now a good time to break things?

    Should the new data type still be called apr_time_t?  (My own
    preference is to change the name so that existing applications
    will break predictably at compile time rather than unpredictably
    at run time.)

--Brian

Re: next steps for changing apr_time_t?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 11:46 AM 7/8/2002, Tony Finch wrote:
>On Mon, Jul 08, 2002 at 01:20:24AM -0700, Aaron Bannert wrote:
> >
> > I am strongly opposed to reusing the apr_time_t identifier.
>
>I note that apr_time_t is a bad name in the first place, because POSIX
>reserves all names ending in _t for the implementation. Feel free to
>ignore this exceedingly irritating naming rule :-)

+1, all agreed here.  ANSI reserved all _prefixed names for the clib, and
that is one we respect.  We always prefix symbols with apr_... and
an implementation with an apr_xxx_t type would be extremely unlikely.

Bill

Re: next steps for changing apr_time_t?

[Cliff Woolley <jw...@virginia.edu>]

On Mon, 8 Jul 2002, Tony Finch wrote:

> I note that apr_time_t is a bad name in the first place, because POSIX
> reserves all names ending in _t for the implementation. Feel free to
> ignore this exceedingly irritating naming rule :-)

I think we uniformly ignore this rule already.  Everything in APR that I
know of already has a _t suffix (APR-util doesn't follow this standard
consistently -- many things in APR-util, including buckets, XML stuff, and
strmatch patterns, leave off the _t).  I remember when we had this
discussion last, and as I recall, everybody agreed it was a stupid rule.
:-]

--Cliff

Re: next steps for changing apr_time_t?

[Tony Finch <do...@dotat.at>]

On Mon, Jul 08, 2002 at 01:20:24AM -0700, Aaron Bannert wrote:
> 
> I am strongly opposed to reusing the apr_time_t identifier.

I note that apr_time_t is a bad name in the first place, because POSIX
reserves all names ending in _t for the implementation. Feel free to
ignore this exceedingly irritating naming rule :-)

Tony.
-- 
f.a.n.finch <do...@dotat.at> http://dotat.at/
FAIR ISLE: CYCLONIC BECOMING SOUTHERLY 5 TO 7, BACKING SOUTHEASTERLY 3 OR 4
LATER. RAIN AT TIMES. MODERATE OR POOR BECOMING GOOD.

Re: next steps for changing apr_time_t?

[Aaron Bannert <aa...@clove.org>]

On Mon, Jul 08, 2002 at 12:46:04AM -0700, Brian Pane wrote:
>     How much will this impact other APR-based apps (SVN, Flood, etc),
>     and is now a good time to break things?
> 
>     Should the new data type still be called apr_time_t?  (My own
>     preference is to change the name so that existing applications
>     will break predictably at compile time rather than unpredictably
>     at run time.)

I am strongly opposed to reusing the apr_time_t identifier. In my mind,
we should do the two things separately: 1) create and start using
binary usecs, and 2) decide* how to deprecate the apr_time_t interface.

*This is all a matter of how nice we want to be. I'm leaning toward
keeping the apr_time_t interface for awhile. Another good option might
be to cause some compile-time breakage that makes the change obvious.

-aaron

Re: next steps for changing apr_time_t?

[Justin Erenkrantz <je...@apache.org>]

On Mon, Jul 08, 2002 at 12:46:04AM -0700, Brian Pane wrote:
>     How much will this impact other APR-based apps (SVN, Flood, etc),
>     and is now a good time to break things?

Flood shouldn't be too bad to convert as it isn't that large.
SVN only knows that apr_time_t is in usec's in very few places, but
there are a lot of places where apr_time_t is passed to these helper
functions.

So, a rename would hurt a lot more than just breaking the
apr_time_t value.  Since APR isn't 1.0, I'm not that concerned about
backwards-compatibility.  And, apr_time_t seems like the best name.

If you can post any patches a few days before committing them, I
can try to get corresponding flood and SVN patches ready for when
you commit to httpd-2.0/APR.  -- justin

Re: next steps for changing apr_time_t?

[Brian Pane <br...@apache.org>]

William A. Rowe, Jr. wrote:

> apr_time_t is what it is.  But there are a few old-school coders who 
> believe
> that apr_foo_t is nothing but a wrapper for the well-known foo_t.  To 
> appease
> everyone, we need to rename this more explicitly.  I would suggest the 
> final
> name of apr_time_busec_t (if we go with a busec implementation.)  Do the
> same to all apr_time_xxx functions and macros. 


I have reservations about a *busec* name.  That name would
imply a specific implementation, but this should be an abstract
type for better maintainability.  (Fortunately, our new macros,
apr_time_sec() et al, allow us to make it abstract without any
performance loss.)

--Brian

Re: next steps for changing apr_time_t?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 02:46 AM 7/8/2002, you wrote:
>Based on the votes in STATUS, there's a consensus in favor of changing
>from the current apr_time_t implementation to a binary microseconds
>implementation.  Meanwhile, I've removed most of the dependencies on
>the old design from the httpd-2.0 code.

The next step doesn't require any of the decisions below, though I'll offer
my comments and observations.  First;

You simply need to replace the macros with BUSEC computations.  Don't
bother with the symbol names.  Then profile.

I don't think anyone wants to consider this change until we know the
performance impact :-)

>A couple of important questions remain, though:
>
>     How much will this impact other APR-based apps (SVN, Flood, etc),
>     and is now a good time to break things?
>
>     Should the new data type still be called apr_time_t?  (My own
>     preference is to change the name so that existing applications
>     will break predictably at compile time rather than unpredictably
>     at run time.)

apr_time_t is what it is.  But there are a few old-school coders who believe
that apr_foo_t is nothing but a wrapper for the well-known foo_t.  To appease
everyone, we need to rename this more explicitly.  I would suggest the final
name of apr_time_busec_t (if we go with a busec implementation.)  Do the
same to all apr_time_xxx functions and macros.

The other alternative for shorter names is apr_butime_ or apr_utime_ (binary
or decimial micro-time units).

Bill