> 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
