commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Henderson" <>
Subject RE: [codec] Streamable Codec Framework
Date Wed, 05 Nov 2003 06:44:31 GMT
> >  Pipelineable codecs.  This allows multiple codecs to be chained  
> > together and treated as a single codec.  This allows codecs 
> such  as 
> > base 64 to be broken into two components (base64 and line  wrapping 
> > codecs).
> We have something similar in James were we handle 
> dot-stuffing (actually, we have several specialized stream 
> transforms).  Are you using FilterInputStream?

Both CodecInputStream and CodecOutputStream use FilterInputStream
and FilterOutputStream respectively.

As I believe you were alluding to, one method for chaining multiple
codecs together is to use multiple CodecXXXStreams together with a
single CodecEngine implementation used by each.

Alternatively the ChainEngine can be used to wrap multiple
CodecEngine instances together into single logical units and the
ChainEngine used in a single CodecXXXStream instance.  For output
streams the difference may only be one of semantics but for input
streams I believe the performance difference would be considerable.
Perhaps this indicates issues with the design of CodecInputStream
but I couldn't think of a more effective way of dealing with
CodecEngine instances in a generic manner.

> >  Single OutputStream, InputStream implementations which  
> utilise codec 
> > engines internally.  This eliminates the  need to produce a buffer 
> > based engine and a stream engine  for every codec.
> Seems like it would be good to support NIO as well.

I don't have experience with NIO (yet another task on my
TOLEARN list ;-), any hints or suggestions on what it would take
to support NIO would be appreciated.

> >
> I'll take a look when I get back into the office.  From your 
> list of things to be fixed, seems you've a good handle on it.
> The other thing I want is a stream-based regex matcher.  
> Doesn't need to be full Perl; awk would be fine.

This brings up an interesting point.  The current implementation
pays no attention to Strings, only bytes.  Would regular
expressions require String (or StringBuffer) support?  If so
it may require the addition of a new codec engine type that
operates on strings.  This may be necessary for XML manipulation
as well.

Note that if an engine is configured using methods accepting
Strings but still processes byte arrays then the existing model
fits (ie. Regular expressions specified as strings but matching
performed on byte sequences).

I haven't thought any of this through yet though so I'm unsure
how it could fit into the existing design.  I don't want to
add new methods to the existing CodecEngine interface because
it is designed for performing transforms on byte sequences
and nothing else.  I see string manipulation as a related but
separate issue (perhaps requiring addition of new interfaces).

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message