mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Im" <im-ja...@hotmail.com>
Subject Re: Making ProtocolEncoder and ProtocolDecoder independent from IoSession
Date Fri, 17 Aug 2007 15:49:42 GMT
>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 opinion is the following: I like the current coupling. Abstracting
too much adds complexity and is less powerful.

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


Mime
View raw message