apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: apr-iconv 1.0
Date Thu, 31 Mar 2005 18:28:55 GMT

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.

View raw message