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 - >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.
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 :) Bill
