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.
