William A. Rowe, Jr. wrote:
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?
The one we're using is version 1.0 from Konstantin Chugev, and IIRC it's
a BSD thing. In the meantime, he's released 2.0.
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 think we are, yes.
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.
+1. I don't see why we'd need a separate apr-iconv public API, since we
already have apr_xlate.
-- Brane
