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 Wed, 30 Mar 2005 18:41:54 GMT
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

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


View raw message