> (3) Should the Producer/Consumer framework submitted be > retrofitted into the current [codec] Encoder/Decoder > framework? Personally, I like the specificity of "Encoder" > and "Decoder" for interfaces. This means the current i/f > would be expanded.
I'm not terribly attached to Producer and Consumer but couldn't think of a better alternative. Perhaps Source and Sink but they may be no better. I'm not keen on Encoder and Decoder because I don't believe there's a need to make the distinction between the two, plus I might have to rewrite some code ;-) Both encoders and decoders are processing data, it is the algorithm that decides if it is encoding or decoding. In some cases the words encode and decode may not make sense. If you're modifying line endings on a file are you encoding or decoding? Producer and Consumer relate to different things. Base64Encode for example implements ByteProducer and ByteConsumer by way of the ByteEngine interface because it consumes byte data and produces byte data. OutputStreamConsumer only implements ByteConsumer because it consumes byte data but sends the data to a location outside the scope of the library (ie. OutputStream). > > (4) The other way around: should the current [codec] be > recast in the proposed Produced/Consumer f/w. I am not wild > about the genericity of "Producer" and "Consumer" as names. > > (5) I am assuming that two f/w's in [codec] are undesirable. > It would be good to agree or disagree on this previous > statement as a starter! ;-) There are obviously advantages to having a single unified framework and if possible it would be the ideal result. Unfortunately I have run into performance disadvantages so far. I haven't tried it for a while but in the past my base 64 conversion has not been as fast as the existing codec implementation for small conversions. For common algorithms such as base 64 it may make sense to have two implementations optimised for different purposes. In addition, I'm not familiar with language codecs but you mentioned it makes no sense to use these in streams. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
