Hello, Streamable codecs make a lot of sense for some codecs (but perhaps not for the language codecs). Thanks for bringing the topic up. I took a very quick look at the code you refer to and it seems to be a separate framework from what we have in [codec] today (I could be wrong of course), especially the whole Producer/Consumer business.
A simple example I can think of that could drive an implementation could be: InputStream inputStream = ... new File(...); DigiestUtil.md5Hex(inputStream); It would be interesting to see how Ant implements MD5 and SHA. This probably means that Encoder.encode(Object) should also handle I/O/Streams and Reader/Writer... Gary > -----Original Message----- > From: Brett Henderson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 06, 2004 18:29 > To: 'Jakarta Commons Developers List' > Subject: RE: [codec] Streamable Codec Framework > > There seemed to be definite interest in streamable > codecs but the list has gone fairly quiet. > > I am interested in participating in work of this > kind but I'm not sure how to proceed. > > I don't think this deserves to be a standalone > project as it seems to fit fairly well into the > scope of the current codec package and I don't > want to step on any toes with respect to the > existing codec project. > > I believe Gary Gregory and Tim O'Brien are the two > primary codec committers. Gary and Tim, your thoughts > would be most appreciated. > > I'm providing the code mentioned in the below > message as an example because I believe it is more > effective to discuss working code than talk about > abstract ideas. > > > -----Original Message----- > > From: Brett Henderson [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 13 November 2003 10:33 AM > > To: 'Jakarta Commons Developers List' > > Subject: RE: [codec] Streamable Codec Framework > > > > > > I made some changes to the code I supplied previously, it can > > be found at the following URL. > > > > http://www32.brinkster.com/bretthenderson/BHCodec-0.5.zip > > > > The main differences relate to the codec interfaces and > > support for data types other than "byte", the encoding > > algorithms are largely unchanged. > > > > A quick summary of the framework is as follows: > > > > Framework is based around consumers and producers, consumers > > accept incoming data and producers produce outgoing data. A > > consumer implements the Consumer interface and a producer > > implements the Producer interface. > > > > Specialisations of these interfaces are used for each type > > of data to be converted. For example there are currently > > ByteConsumer, ByteProducer, CharConsumer and CharProducer interfaces. > > > > The engine package contains classes (and interfaces) that > > are both consumers and producers (ie. accept incoming data > > and produce result data). For example there is a ByteEngine > > interface that implements ByteConsumer and ByteConsumer > > interfaces and is in turn implemented by the Base64Encode > > concrete class. > > > > Engines may consume one kind of data and produce another, > > the CharByteEngine interface defines an engine that > > consumes characters and produces bytes. This is implemented > > by the CharSetEncode class (untested). > > > > The consumer package contains classes that consume data > > and perform an action on the data that doesn't allow it to > > be accessed via producer functionality. For example, the > > BufferByteConsumer class acts as a receiving buffer for > > encoding results, the OutputStreamConsumer writes all data to > > an OutputStream. > > > > The producer package contains classes that produce data > > for the framework but don't accept data via consumer > > functionality. For example, the OutputStreamProducer is an > > OutputStream that "produces" all data passed to it. > > > > The io package contains classes that fit into the java.io > > functionality that are neither consumers or producers in the > > framework sense. For example, the CodecOutputStream is a > > FilterOutputStream that uses an internal ByteEngine to > > perform a transformation on the data passing through it. > > > > JUnit tests exist for most classes in the framework. > > All testing is performed using JUnit. If there is no unit > > test for a class, it can be considered untested. > > > > The framework is now generic enough to handle data of any > > type and allow classes to be defined which can accept > > any kind of data and/or produce any kind of data. All > > data can be processed in a "streamy" fashion. For example, > > encoding engines implementing the ByteEngine interface can be > > plugged into CodecOutputStream or CodecInputStream and used > > for stream functionality without directly supporting java.io streams. > > > > Using the CharSetEncode and (currently non-existent) > > CharSetDecode, it should be possible to encode character data > > to base64 then write result to a Writer. This should go part > > way towards helping Konstantin with his XML conversions. > > > > Sorry about the brain dump but there is a fair bit > > contained in the zip file and I thought some explanation > > would be useful. > > > > Any feedback on the above is highly welcome. I don't > > plan on making too many more changes unless it is > > deemed useful. > > > > Brett > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
