commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ola Berg" <ola.b...@ports.se>
Subject Re: [codec] Handling text encodings (one more thing, sorry)
Date Tue, 19 Nov 2002 14:32:09 GMT

> Maybe we need two concepts:
> 
> 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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message