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.
