RE: [codec] Streamable Codec Framework

[Brett Henderson <ja...@bretth.com>]

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