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 20:05:08 GMT

On Mar 31, 2005, at 1:23 PM, William A. Rowe, Jr. wrote:

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

Mladen's suggestion appeared to be drop apr-iconv and require Windows 
users of apr_xlate to depend on gnu iconv.  Using gnu iconv as an 
option is okay, but it doesn't eliminate the need to provide or 
identify an iconv implementation that is consistent with the Apache 
License.

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

I was trying to explain a course of action that could address one of 
the complaints (and maybe the major one) without needing to launch a 
new project or incorporate a new code base so I don't see it as just 
implementation details.  Maybe a new BSD licensed iconv project might 
make that approach moot at some point in the future and we could drop 
apr-iconv, but it exists now and has a degree of familiarity.

I've done a little exploration using macro instead of C++ namespaces 
and the most significant issues is that iconv_ccs_desc and 
iconv_ces_desc atr used both as a structure name and as a instance name 
and I can't use a macro to rename one without affecting the other.  
However, it would be a fairly insignificant change to change to names 
of the local instance variable so the structure and the instance can be 
distinguished.  So unlike the namespace approach, it can't be done with 
no changes to the module code, but it can be done with a small change 
that does not affect their ability to still be used in the module based 
approach.

I'm overbooked as it is.  I am able to make do with the current 
apr-iconv and am only concerned with approaches that might leave me 
stranded without an option on Windows platforms.


Mime
View raw message