> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
