apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr-iconv 1.0
Date Thu, 31 Mar 2005 19:23:05 GMT
At 12:28 PM 3/31/2005, Curt Arnold wrote:

>On Mar 31, 2005, at 5:27 AM, Mladen Turk wrote:
>>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.

Two separate issues.  Apache projects regularly support linking
to gnu libraries, such as the native install of regex or expat or
whatever code the GNU communities have co-opted.

I'm against providing GNU-only services from apr, and believe many
here agree.  I don't agree with inhibiting the same.  The user should
be able to configure for either, if that's what they want to do.

The difference, we wouldn't distribute a binary linked to GNU code
from the foundation.  If third parties care to, that's fine.
I don't have any objection to Mladen's suggestion, as one alternative
among many.

>>Like said, I think that we should either build our own
>>implementation of iconv functionality, or just build a wrapper
>>over existing one.

Mladen, you didn't define 'we'.  The apr project has proved less
than enthusiastic about creeping featurism.  'We' definitely want
out from iconv support, from the majority of posts I've read.

>>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.

More to the point, we should have some iconv code base to rely
on.  A wider community iconv implementation.  Not one which is
hacked beyond recognition to use the apr interface, which enjoys
only limited adoption.

>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.

Those are implementation details.  I've added Mladen to the list
of individuals interested in seeing a BSD-licensed iconv project.
Brane was already on that list, and I'm inquiring in the BSD and
the newlib communities.  Should I add you to that list as an 
interested participant, Curt?


View raw message