apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: apr-iconv 1.0
Date Wed, 30 Mar 2005 21:50:46 GMT

On Mar 30, 2005, at 2:40 PM, William A. Rowe, Jr. wrote:

> At 01:02 PM 3/30/2005, Curt Arnold wrote:
>
>> If apr-iconv is an implementation detail of apr_xlate, then I don't 
>> see the significance of deprecating it.  Either it (or a replacement) 
>> is needed to support apr_xlate on platforms that don't provide an 
>> iconv or apr_xlate needs to be deprecated or removed.
>
> We drop it.  Point users 'elsewhere'.  "Not Maintained Here"
> sign on the door.  Tarball moves to archive.apache.org.  Perhaps
> same for svn repository.
>
> Obviously we want apr_xlate to point at -something- but the what
> would no longer be apr_iconv.
>
>> I assume that Subversion is actually using apr_xlate or they would 
>> not have bothered with setting APR_ICONV_PATH.  Does httpd use 
>> apr_xlate?
>> If so, I don't see how you could deprecate apr_xlate or make it only 
>> available on Unix platforms.
>
> Well, subversion does use apr_xlate.  But this was actually reported
> by our log4cxx devs, who tripped over the subversion copy when they
> thought they were using their own build.
>

I made the initial report when attempting to use apr_xlate in log4cxx.

What I saw trying to say was that Subversion would likely have not set 
APR_ICONV_PATH in Windows unless they were using apr_xlate.  So 
removing apr_xlate on Windows would likely break Subversion on Windows. 
  It may also break or reduce the functionality of httpd on Windows, but 
that is speculation.  I would not see dropping apr_xlate on platforms 
that don't have a native iconv implementation as acceptable.

I could see several potential interpretations of "deprecating 
apr-iconv" and the proposal needs to be clarified for a vote to be 
meaningful.  Here some of the potential interpretations:

1. Drop apr_iconv and suppress apr_xlate on platforms without a native 
iconv implementation.

2. Drop apr_iconv and support apr_xlate on platforms without a native 
iconv implementation using something else.

3. Drop apr_iconv and suppress apr_xlate on platforms without a native 
iconv implementation, but add another translation method that can be 
supported by the Windows API and iconv.

I don't think interpretation 1 could be supported since Subversion and 
likely httpd depend on apr_xlate and want to run on Windows platforms.  
Interpretation 2 would depend on the nature of the "something else".  I 
assume the minimum requirements would be support on Windows and an 
Apache compatible license.  I would assume that there would be 
resistance to interpretation 3.

I could support option 2, but would need to know the identity and 
licensing terms of the "something else" first.


Mime
View raw message