Return-Path: 
 <new-httpd-return-10200-apmail-new-httpd-archive=apache.org@apache.org>
Delivered-To: apmail-new-httpd-archive@apache.org
Received: (qmail 72613 invoked by uid 500); 21 Nov 2000 23:06:47 -0000
Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
list-help: <mailto:new-httpd-help@apache.org>
list-unsubscribe: <mailto:new-httpd-unsubscribe@apache.org>
list-post: <mailto:new-httpd@apache.org>
Delivered-To: mailing list new-httpd@apache.org
Received: (qmail 72576 invoked from network); 21 Nov 2000 23:06:46 -0000
Errors-To: <wrowe@rowe-clan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <dev@apr.apache.org>, <new-httpd@apache.org>
Subject: iconv features
Date: Tue, 21 Nov 2000 17:06:43 -0600
Message-ID: <000501c0540f$b7ab18a0$92c0b0d0@roweclan.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Q to the lists;

  our existing charset translation is based on iconv.  Based on
that, I dropped iconv into the repository, and Jeff, Ryan and I
rearranged after that.

  Looking deeply into this, I'm bringing up ICU once again.  It
has several side-issues, but I believe we would be better off basing
our conversions on this package.  See:

http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html?dwzone=opensource

             iconv                              ICU
flexible     No, that's all it does             Yes, knows locales, etc
License      BSD w/advertising clause           IBM Public License
Size         Fairly large, w/extra&rfc1345      Absolutely huge
any<>any     Yes, there is a x<unicode>y thunk  No - we need to code it
portability  No, this is a BSD implementation   Yes - it's already ported
pure c       Yup                                Nope, has cpp mixed in

  We need to do one of two things.  If we are going to use iconv, I will
adapt it for apr (especially data types and dso support!)  If we are going
to use ICU, I need to write the any <> unicode <> any layer that emulates
iconv behavior.  The apr'ized implementation obviously belongs in APR.
Does ICU?  I don't have an answer.

Submitted for your consideration and comments,

Bill