Mladen Turk wrote:
OTOH, the xlate would go to it's proper place, because it is a part of apr-iconv.
Nope, you got it entirely upside down. apr_xlate is a simple (not quite simple enough) interface for encoding translations. If it's via iconv, or libiconv, or any other codepage transformation library is irrelevant.
The reason is simple. If someone needs xlate stuff, then he will use apr-iconv.
No - that's not how it works. As much as I'd *like* to see apr folk help to support apr-iconv, the point is to provide apr_xlate to speak at whatever iconv or other translation library is available. That would even be happening on windows, except that the native flavor (forget the COM-based junk) won't do partial string resolution, something required of any sane translator (as MS later realized while writing their com-thunked flavor.) E.g. I have a source and dest buffer of 4096 bytes, and the source buffer is full, when we go from sbcs to mbcs of one sort or another, the dest is going to fill up too quickly, and overallocating dest buffs by a factor of 3 is not reasonable for a general purpose api. Now that we've squashed your thought, let me spin your desired result a bit differently. A few of us *have* come to the conclusion that apr-util is crap. At the moment it hauls in a number of libraries, which makes moving binaries around a rather worthless exercise in futility. The right answer is to break apart apr-util into seperately loadable libraries in APR-util v2.0 - so that all those dependencies are split, and it begins to look alot more like the way that python, perl, and jar support of these various features break apart all the subdependencies. apr_xml becomes one lib, apr_xlate becomes another, apr_ldap becomes a third, etc. But understand that apr-util should -only- consist of helper code to normalize these various library api's - and help the user leverage, say, ldap - no matter if they have openldap, sun's ldap or ms ldap api's available. Likewise with apr-iconv; by v2.0 I expect we pitch this altogether and (for win32) write the patch which ports bsd iconv, end of story. If the user chooses to link to libiconv, or IBM's i18n libs, that should be their choice (bsd iconv simply because it's easiest for ASF binary distributions.) Bill
