Q to the lists; our existing charset translation is based on iconv. Based on that, I dropped iconv into the repository, and Jeff, Ryan and I rearranged after that.
Looking deeply into this, I'm bringing up ICU once again. It has several side-issues, but I believe we would be better off basing our conversions on this package. See: http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html?dwzone=opensource iconv ICU flexible No, that's all it does Yes, knows locales, etc License BSD w/advertising clause IBM Public License Size Fairly large, w/extra&rfc1345 Absolutely huge any<>any Yes, there is a x<unicode>y thunk No - we need to code it portability No, this is a BSD implementation Yes - it's already ported pure c Yup Nope, has cpp mixed in We need to do one of two things. If we are going to use iconv, I will adapt it for apr (especially data types and dso support!) If we are going to use ICU, I need to write the any <> unicode <> any layer that emulates iconv behavior. The apr'ized implementation obviously belongs in APR. Does ICU? I don't have an answer. Submitted for your consideration and comments, Bill
