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: iconv - mistake #27?
Date Sun, 09 Oct 2005 23:37:40 GMT
Branko ─îibej wrote:
> William A. Rowe, Jr. wrote:
>> If we drop xlate, obviously those modules could directly consume iconv -
>> that would be the choice of the httpd project.
> Do I smell an "APR == Apache *HTTPD* Portable Library" rat again?

Actually no, I don't suppose that's a real issue; as I suggested *any*
module can include iconv.h, it isn't really portability.

> apr_xlate hides the differences between apr_iconv and "ordinary" iconv. 
> Subversion for one relies on having this abstraction layer.

The point is; why apr_xlate?  Why not a mingw build of iconv?  Why not
a win32 LPGL port of libiconv?  Why not a newer truly portabable iconv
implementation (I have a draft of the BSD licenced, v 2.1 successor to
the old standby 2.0.3 version sitting around.)

> If anyone's worried about (L)GPL'd iconv being pulled into their 
> oh-so-proprietary APR-based binaries, then by all means use apr-iconv on 
> Unixen, too. It's supposed to work, isn't it?

It should, but nobody has tested it.

I did mean to say that this wouldn't change until apr-util 2.x - and am
not opposed to continuing apr-iconv (especially if it becomes nothing
but a porting help to a very tightly BSD implementation.)

But apr-iconv needs eyes that it doesn't have; I've had a 1.1.1 tarball
candidate out there over a week, based on long, productive threads about
how apriconv-0.x and apriconv-1.x should coexist without breaking any
compatibility.  I hope the last patches accomplish that, and that the
next patches make the 'lib/iconv' directory even easier to determine
without any envvars.

If apriconv gets some eyeballs and +1's that we have moved in the right
direction, I'd be much less eager to strip out something that, to me,
really doesn't look like it enhances platform/application portability.


View raw message