[apr-iconv] State of the union

[Mladen Turk <mt...@apache.org>]

Hi,

It seems to me that only WIN32 platform actually uses apr-iconv.
All others platforms are dependent on system provided iconv library.

Further more the iconv 1.0 sources from Konstantin Chuguev that
originates from FreeBSD are way outdated and are not maintained
for years, so all the complaints about modifying the 'original'
sources are at least pretentious.

Now, the pragmatic question is:
If apr can use system provided iconv, what are the platforms
supported by the apr-1.2+ that do not provide their own iconv
and for which we *must* have spr-iconv.
AFAICT this is only the windows.

If that is the case I wonder what is the purpose of maintaining
the full platform compatibility for the apr-iconv if in the
real life it's used only on windows (at least the trunk).

Regards,
Mladen.

Re: [apr-iconv] State of the union

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Mladen Turk wrote:
> 
> It seems to me that only WIN32 platform actually uses apr-iconv.
> All others platforms are dependent on system provided iconv library.

This is either clib (no issue) or libiconv (small issue, LGPL, not
quite as viral.)

> Further more the iconv 1.0 sources from Konstantin Chuguev that
> originates from FreeBSD are way outdated and are not maintained
> for years, so all the complaints about modifying the 'original'
> sources are at least pretentious.

Correct.  The question is, does apr want to maintain in the long
haul?  At the present we have advertised this as an apr-internal,
not a public API - the apriconv headers aren't copied (although
the versioning rules are enforced).

> If apr can use system provided iconv, what are the platforms
> supported by the apr-1.2+ that do not provide their own iconv
> and for which we *must* have spr-iconv.

Must?  That's strong - none need it.  apr_xlate can always return
APR_ENOTIMPL.

> If that is the case I wonder what is the purpose of maintaining
> the full platform compatibility for the apr-iconv if in the
> real life it's used only on windows (at least the trunk).

We aren't - I'm proposing to kill the subproject at the end of apr-1's
lifetime, with no bindings from apr-2.  At least, that's the thought.

I'm working on a port of the only SUPPORTED BSD implementation out there,
the Citrus implementation within BSD's clib.  This is by a mostly Japanese
team of BSD users who wrote and appear to actively maintain it - this
even ships in BSD 3.0.

Fyi - the netlib folks also have an implementation as well, IIRC, based
originally on the Konstantin sources IIRC.  Also it can be done with IBM's
ICU, but this is more like taking a sledgehammer to a pushpin :)

The reason apr-iconv no longer interests me is that the places it's most
critical, libxml2/libxslt aren't going to be able to use it.  As part of
the Unix98 and later and targeted at the next formal C language spec...
it seems pointless to keep apr-iconv swimming.

I'm still not keen on introducing LGPL code, but since the winds have
shifted at the ASF, and we -can- even employ libiconv (at least for our
binary distributions) - do we want to take this shortcut?  Or pursue
the Citrus port instead?

Last week I spent 30 hours in MLang API hell (MS's COM interface to iconv-
like stuff) and was thoroughly disappointed.  I'll share the conclusions
and sources if anyone's interested, but in short - it doesn't distinguish
to the caller between incomplete multibyte at EOS, invalid translation and
out of buffer - even through the IErrorInfo interface, and doesn't perform
partial conversions, the string is unicode'd to the destination buffer and
the transformed in place, so a partial conversion is only to-unicode.  So
my sacrifice to accept a bit of COM within apr proved hopeless for now :)

The best hope of a lightweight (codesize wise) MLang/Win32 API solution
is to do the char-by-char conversion.  Not a very fun prospect, but I
might just tackle it out of pure frustration.  Distributing extra copies
of codepages that every user has installed with MS's xml / IE is redundant.

Anyways - that's my feedback for you on the state of apr-iconv from my
own perspective.