Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 33806 invoked from network); 19 Nov 2002 14:31:48 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 Nov 2002 14:31:47 -0000 Received: (qmail 27870 invoked by uid 97); 19 Nov 2002 14:32:45 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 27854 invoked by uid 97); 19 Nov 2002 14:32:45 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 27842 invoked by uid 98); 19 Nov 2002 14:32:44 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <032e01c28fd8$71236c50$3f1ea8c0@ports.local> From: "Ola Berg" To: "Jakarta Commons Developers List" References: <001201c28fd5$d25a1440$6f34fea9@tobrien> Subject: Re: [codec] Handling text encodings (one more thing, sorry) Date: Tue, 19 Nov 2002 15:32:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > Maybe we need two concepts: >=20 > A ChunkCodec - like Soundex, Metaphone, Refined Soundex, Message > digests.... > And a StreamCodec - like Base64, Rot13, compression algorithms, sound > encoding... Sun dealt with the IO in a block/stream neutral way, where InputStream = provides a stream oriented view on block oriented media and vice versa. = InputStream completely hides the underlying media's orientation. I don't = like it. OTOH, I like its possibility to view it in a unified way. Lots of munching algorithms benefits or needs chunks (Base64 for one), = where the implementation has to fake a completely streams based view. = Writing the algorithm in a block oriented way is easy, the problem is to = interface with it. The problem with a codec interface that takes String as input is that = there are few algorithms that will benefit from taking strings of = arbitrary length. Different chunk oriented algorithms works at the = lowest level with different chunk sizes and types. Ideally, you want it to be easy to write the codec, in a way that suits = you. Then you want to interface with it in another way. Smells like some = kind adapter task/ server provider interface. Suggestions? /O -- To unsubscribe, e-mail: For additional commands, e-mail: