apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <da...@jetnet.co.uk>
Subject Re: apr-iconv 1.0
Date Wed, 23 Jun 2004 23:30:45 GMT
> I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 -
they
> 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
1.0.

> 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.

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.

david


Mime
View raw message