text: On Mar 31, 2005, at 5:27 AM, Mladen Turk wrote:
  > William A. Rowe, Jr. wrote:
  >>>
  >>> Well, I'm interested if the final product will not depend on a
  >>> hundred or so separate .dll's for each and every charset, and
  >>> if apr_util will not depend on apr_iconv.
  >> I'd see that as advantage as well. I understand loadable
  >> modules for complex translations, but not for tables.
  >>
  >
  > I would like that we first resolve the static linking of
  > apr-iconv to apr-utils, and using apr_dso_* for
  > apr_iconv functionality. For me that is the major issue.
  For log4cxx, I've replaced the module loading code so that all the
  encodings are present within liblog4cxx.so and/or log4cxx.dll. To do
  this, I included the module definitions inside C++ namespace blocks to
  prevent symbol collision. Obviously that is not an appropriate
  approach for apr-iconv itself, but it seems likely that you could do a
  similar thing using preprocessor macros instead of C++ namespaces.
  >
  > I'm sure we can think of something, but if you say that we
  > can not use native WIN32, then we could at least offer the
  > option to use gnu-iconv for win32 builds as well, or any other
  > iconv-api library.
  How could gnu-iconv be an option for an Apache project due to the
  license conflicts? There don't seem to be any appropriate iconv
  implementations for Windows.
  > Like said, I think that we should either build our own
  > implementation of iconv functionality, or just build a wrapper
  > over existing one.
  >
  > So, I see the future of apr-iconv as ASF implementation of
  > iconv, with iconv abstraction layer moved to apr-utils, that
  > will use apr-iconv, as just one of the flavors of iconv api.
  >
  I'm not sure how that is different that the current state. Currently,
  apr_xlate in apr-util will use a native iconv implementation if one is
  detected in configuration, otherwise it will use apr-iconv. If you
  don't want to ever use the native iconv implementation, you could
  probably force that in the configuration script.
  If the only issue is the packaging (modules vs monolithic), that likely
  could be addressed by some fancy macro usage and inclusion of the
  current code base. If someone wants me to attempt it, I'd me willing
  to give it a shot. It appears that none of the potential iconv
  implementations has a vibrant community and that trading the dormant
  apr-iconv community for a dormant FreeBSD iconv community might not buy
  us much if the major issue with apr-iconv is packaging.