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.
