James, On 8/17/07, James Im <[EMAIL PROTECTED]> wrote: > > >If what ProtocolEncoder and ProtocolDecoder do with IoSession is just > >to access user defined attributes, we could simply remove the coupling > >with IoSession and replace it with java.util.Map (or ConcurrentMap). > >By doing this, we can make our codecs reusable across various > >applications, even that don't use MINA as a network layer. > > making the codecs reusable across various applications ... outside > mina... Is there a real demand for such use case? If not, I personally > prefer the current design which appears to be more simple and more > powerful (IOSession is the gateway to access MINA specific info).
My first thought was like yours: Is there demand for this ? Personally I don't care that my codecs depend on mina. But the codecs will certainly become easier to test this way. And that's a huge benefit. But ok, the IndependentProtocolDecoder would also have this benefit. I am just not sure that's less complex :-) My opinion is the following: I like the current coupling. Abstracting > too much adds complexity and is less powerful. sometimes it's hard to give up some power. For me a better way to obtain the decoupling you're looking for would be > to create two other interface (IndependentProtocolDecoder and > independentProtocolEncoder) that would not depend on anything (or may be > just ByteBuffer). Then I would create an implementation of > ProtocolDecoder/ProtocolEncoder that wraps an instance of > IndependentProtocolDecoder /IndependentProtocolEncoder for its use with > mina. Is your suggestion of an IndependentProtocolDecoder different from what Niklas suggested ? I also thought about going that route but I wonder if we can still benefit from existing helper classes like CumulativeProtocolDecoder when implementing an IndependentProtocolDecoder. (I would have to try it out before I could say more about it.) Will think about it some more over the weekend ... Maarten By doing this, you can decide if you need to be coupled with mina or if > you want to be decoupled from mina. All options are opened. > > > PD: If the independent protocol codec is still coupled with the > ByteBuffer class I don't know if the whole process makes sense. If the > 'independent' code is still dependent on one mina class, it can be > dependent on a couple more classes too... > > _________________________________________________________________ > Download din yndlingsmusik på MSN Music: http://www.msn.dk/music - det > er > nemt og billigt > >
