Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
In-Reply-To: <6.2.1.2.2.20050330143751.05a8c380@pop3.rowe-clan.net>
References: <6.1.0.6.2.20040623142928.07b85ec0@pop3.rowe-clan.net>
 <40E4A125.2000206@xbc.nu>
 <6.1.0.6.2.20040702022101.0413ee38@pop3.rowe-clan.net>
 <40E59F80.8020000@xbc.nu>
 <6.2.1.2.2.20050329164227.02df2eb0@pop3.rowe-clan.net>
 <424AD10E.1020905@apache.org>
 <6.2.1.2.2.20050330121850.067c4340@pop3.rowe-clan.net>
 <9d0a8bf22175edaf72d06d1b6e36eca3@houston.rr.com>
 <6.2.1.2.2.20050330143751.05a8c380@pop3.rowe-clan.net>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3b0b3bc69aebf7891a842ed62b57b63f@apache.org>
Content-Transfer-Encoding: 7bit
Cc: APR Developer List <dev@apr.apache.org>
From: Curt Arnold <carnold@apache.org>
Subject: Re: apr-iconv 1.0
Date: Wed, 30 Mar 2005 15:50:46 -0600
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>


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.