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: Moving apr_xlate from apr-util to apr-iconv
Date Mon, 08 May 2006 17:39:23 GMT
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

Mime
View raw message