At 10:17 AM 3/30/2005, Mladen Turk wrote: >William A. Rowe, Jr. wrote: > >I've developed libxlate library about a year ago, so perhaps >it deserves a second look. It can be integrated within apr-iconv, >because it follows the iconv api. >Since this is my code, I'm willing to donate it to ASF if >accepted for apr-iconv.
The biggest issue is community. apr-iconv clearly hasn't enjoyed enough community to retain the code we have. Contributions and help are scattershot. Our choice to integrate to apr was a poor one, because it doesn't enjoy any adoption outside of the apr user community. Simply, our solution was overkill, and formatting changes made it difficult to maintain in sync with the wider community. libxlate, while it sounds like a slick idea, suffers the same issue. One key point Roy raises is that we shouldn't as a project suffer a dependency on a single individual. You would need to first submit this library to the incubator, and develop a community. I dare say the apr community isn't interested in the nuts-and-bolts of iconv/xlate/charset management. We weren't even interested in continuing serf, it moved from the apr project. You might also consider the apache commons project as a container for libxlate. One concern, you mention you are offering this code under the ASL2, and mention that it follows the GNU single-dll, table-based solution. Did you look at the GNU implementation? I've started a dialog with the BSD-licensed iconv community principals to rebuild some traction for that library. The Linux community couldn't care less, as iconv has been moving into clib. But those not using the gcc compiler will continue to experience issues with iconv support. Once your libxlate is an established project, I see no reason not to set up the detection and configuration code to allow it from apr-util. Choices are good. I'll submit this to vote now, anticipating we want some resolution but don't want to break existing users: Should we deprecate our apr-iconv as of apr-util 2.0? +1: wrowe -1: The resulting issue, plug the hole before apr-util 2.0 is ready. Until that happens, if the vote is affirmative, I'll be happy to modify apr.hw to reflect that apr_xlate is not available on Win32. Bill
