commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [codec] Streamable Codec Framework
Date Fri, 09 Jan 2004 05:14:57 GMT
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:jakarta@bretth.com]
> 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:bretth@mail15.com]
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message