At 12:35 PM 6/25/2004, Branko Čibej wrote: >David Reid wrote: > >>If the answer to the question "does what we have now work" is "yes" then >>apr-util 1.0 is good to go. >> >+1 > >The apr-iconv API is unfortunate, and the fact that it doesn't support >transliteration like GNU libiconv is worse, but most uses of apr-iconv will be >through the apr-util xlate wrapper, so it's not so important to clean up the >API. > >Also, if we're going to change the API, we might as well move base it on the >iconv-2.0 version (we're currently using the 1.0 as a baseline).
Is there a non-[l]gpl iconv 2? I found one is freebsd ports, that I think is the current (and has a new maintainer.) Want to be certain we are speaking about the same one. I'm tempted to say we explicitly declare libapriconv as a private library of libaprutil, just as the bundled expat is, with no public api support. That simplifies things to simply @doxygenate the apr-iconv header to say this is an internal api for use by apr-util, and pointing them to those functions. The goal would be to allow us to redo the latest bsd-licensed iconv to support other platforms, with or without apr, as an opaque dependency. Bill
