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