On 8/18/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 opinion is the following: I like the current coupling. Abstracting
> too much adds complexity and is less powerful.

I agree with you.  Just replacing IoSession with Map might cause the
problems you mentioned.

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

I like you idea.  What about ByteBufferEncoder and ByteBufferDecoder? :)

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

Yes, my purpose is not decoupling from MINA but decoupling from
IoSession, which is often used to access user-defined attributes only.
 By doing so, a codec implementation can be used for non-network
programming.

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Reply via email to