Thanks for the reply. Yep, it is a completely different framework. I wrote the framework before looking at the current commons codec component so there are no relationships between the two. Hopefully there are ways of incorporating ideas between the two.
Are you hoping to incorporate streamed processing into the existing design or create new classes to achieve this? I have no preferences either way but it could be tricky to re-use the existing interfaces. I'll have to look at this further though. I'll look at Ant as soon as I can to see how it approaches the problem. Hmm, your simple example already uncovers a gap in my design :-) Should be easily solved though. Phew. I process all data off an input stream writing to a destination without some manual coding. However I can achieve this by creating a "Producer" that reads InputStreams. I will call this InputStreamProducer. My InputStreamProducer will implement ByteProducer and will have a method (eg. pump()) which pumps data from the provided input stream to the "ByteConsumer" attached to it. Using my new InputStreamProducer I can perform MD5 Hex encoding of an input stream creating a result String as follows: // Create processing objects. MD5 md5 = new MD5(); AsciiHexEncode asciiHexEncode = new AsciiHexEncode(); InputStreamProducer source = new InputStreamProducer(inputStream); BufferByteConsumer resultBuf = new BufferByteConsumer(); String result; // Set up processing chain. source.setConsumer(md5); md5.setConsumer(asciiHexEncode); asciiHexEncode.setConsumer(resultBuf); // Process all available data. source.pump(); // Obtain result hash. result = new String(resultBuf.getData()); If I eliminate all calls to ".setConsumer()" by adding the necessary constructors to accept consumers, the above code can be shortened to. ByteBufferConsumer resultBuf = new BufferByteConsumer(); String result; // Create md5 hash of data from inputStream. new InputStreamProducer(inputStream, new MD5(new AsciiHexEncode(resultBuf))).pump(); result = new String(resultBuf.getData()); What do you think? Static utility methods could simplify the above even further if necessary. It's definitely more complex than the existing approach but it is very flexible in that it allows arbitrary processing chains to be defined and allows for simple integration with IO Streams. Each class performs a very small well defined purpose and can be coupled to build complex processing chains. Processing should be efficient although more setup time is required. Supporting Reader/Writer and any other IO classes should be as simple as defining the relevant Consumer/Producer implementations to interact with them. Codec algorithms won't require modification. Cheers, Brett > -----Original Message----- > From: Gary Gregory [mailto:[EMAIL PROTECTED] > Sent: Friday, 9 January 2004 4:15 PM > To: 'Jakarta Commons Developers List' > Subject: RE: [codec] Streamable Codec Framework > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
