commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Streamable Codec Framework
Date Wed, 05 Nov 2003 03:07:02 GMT
> Given that the current codec implementations are oriented
> around in-memory buffers, is there room for an alternative
> codec framework supporting stream functionality?  I realise
> the need for streamable codecs may not be that great but
> it does seem like a gap in the current library.

If we had them, they could be quite useful within messaging servers.  Having
to process messages in-memory is often undesirable.

>  No memory allocation during streaming.  This eliminates
>  garbage collection during large conversions.

That's the big win.  :-)

>  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?

>  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.

> http://www32.brinkster.com/bretthenderson/BHCodec-0.2.zip

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.

	--- Noel


---------------------------------------------------------------------
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