commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Henderson" <bre...@mail15.com>
Subject RE: [codec] Streamable Codec Framework
Date Mon, 12 Jan 2004 01:59:00 GMT
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:ggregory@seagullsw.com] 
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message