apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr-iconv 1.0
Date Thu, 24 Jun 2004 15:25:37 GMT
At 06:30 PM 6/23/2004, David Reid wrote:
>> I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 -
>> are seperate subsets with their own set of issues.
>> APR 1.0 does not require apr-util or apr-iconv, there is no dependency.
>> So no holdup of David's plans.
>Well, I'd agree on apr-iconv (haven't even rolled a 1.0 rc yet) but apr-util
>needs to be released the same time as apr. Our 2 biggest users (httpd & svn)
>both use both (if that makes sense) so if we have apr 1.0, we have apr-util

Well, we can't ignore apr-iconv, apr-util has a dependency upon it for
those platforms without a native port of iconv.

But nothing precludes us from rolling up apr and dropping it upon the world,
then rolling up apr-util and dropping that 1.0.0 in a separate step.

>> I'm proposing we switch around apr-iconv's interface to:
>> 1) change typedef void *apr_icon_t; to an incomplete type, e.g.
>>    typedef struct apr_icon_t apr_icon_t;
>> 2) consistently use an apr_icon_t * or (for create) apr_icon_t **
>>    as the arguments to the exposed functions.
>> 3) reorder apr_iconv_open to pass the new apr_iconv_t ** placeholder
>>    as the first not last arg, consistent with apr.
>> 4) drop apr_pool_t argument from _close, that should use the same pool
>>    as the associated _open.
>Why does this hold up an apr-util 1.0 ? Please elaborate further.

Because apr-util 1.0 consumes apr-iconv, at least for non-unix distros.

>It does slightly annoy me that there has been a decent sized interval to
>discsuss such issues and only now are they being brought up.

Agreed - wish there were more eyes on the code.  My attention was solely
focused on apr for the past weeks.  I think we very nearly have that right,
so now i'm looking sideways at apr-util and how it could defy developer's
expectations.  And the build breakage pointed out to me how wonky the
current apr-iconv API really was (and mostly, my fault in the first place :)


View raw message