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 18:07:58 GMT
Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
>> 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.
> I disagree.
> The entire point is that it's the translation library.

You are welcome to disagree, but you are wrong.  apr-util are relatively
vanilla bindings around common (but very differently implemented) utility
libraries distributed on many OS's.  They do things like ldap, iconv, dbm.

That's all apr_xlate is - a binding - and there's no way in heck it's moving
into apr_iconv since the bindings can just as easily be written for IBM ICU.

> So, what is the purpose of apr-iconv anyhow?

There's the rub.  It was created because windows (and at the time, some
unices) didn't have a stock iconv provider.  At this point on some of our
platforms, it's in the clib for chris' sake.  So apr-iconv is an optional
provider of the iconv api, for those who need one.

> I suppose to give a translation to platforms not having
> the iconv, right? And that is Windows. So why not name
> the apr-iconv win-icov?

Well, we are gonna make this really really simple and delete the damned
thing after it's final 1.2.0 release(1), and find some decent solution(2),
because there hasn't been a single -productive- iconv discussion thread
for several years now(3), only more silly ones like this.


1. final, presuming I don't just rm it already.  The win64 flaws are a
    good hint that it's past it's prime, and gets no love here.

2. decent solution is either ICU who's license is appropriate IIRC, or
    the bsd iconv option I mentioned earlier.

3. i've attempted to start a dialog with those who maintain and work in
    the iconv area (not libiconv of course) to no avail.  AFAICT it's
    dead, and overtures to help get things moving again weren't ack'ed.

View raw message