> Here are a few good rules of thumb: > > 1. Commons exists as an effort to encourage code reuse. The > Streamable > framework presented was interesting, but I'd like us to find > an existing > streamable Base64 implementation inside of the ASF codebase.
I have no problems with this but so far I haven't seen anything like this that doesn't sub-class InputStream and OutputStream. Sub-classing InputStream and OutputStream is problematic because it forces you to code algorithms around IOStream semantics (InputStream coding is not simple, especially available() method) and it forces you to make the encoder sub-class OutputStream and the decoder sub-class InputStream unless you write an implementation for each stream type. Providing a single InputStream implementation that can use an underlying codec engine simplifies development and testing of new algorithms considerably and removes the distinction between input and output streams. > 3. No need to expressly focus on a framework (at all). Codec > is FIRSTLY a > functional beast, even if the solution is inelegant. If there is an > existing streamable Base64 in ASF, I'd recommend copying it > outright and > placing in the codec package. Over time, it can move towards > a unified > streamable framework. I'm often guilty of over designing things, hey it's fun :-) Would it help if I didn't call my classes a "framework"? It's no more than a few common interfaces and some implementation codecs. There are no factories, or service providers, or other abstractions complicating things. It really isn't much different to the existing codec interfaces except that they are written to support streaming and separate input and output interfaces. I really think there's a need for all streamable codecs to follow common interfaces. Perhaps InputStream and OutputStream are sufficient but I think there's a better way. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
