On 8/18/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> 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 think it's different. Niklas' idea was *not( defining any interface
at all and wrapping custom codec class with the current MINA codec
interface. It's effectively same with doing nothing. :D
IndependentProtocolDecoder idea is to create an extra stripped-down
version of ProtocolDecoder. I like James' idea because it's very easy
for a ProtocolCodecFilter to accept the new interface. Here's an
example:
public class MyCodecFactory implements ByteBufferCodecFactory {
public ByteBufferEncoder getEncoder() { ... }
public ByteBufferDecoder getDecoder() { ...}
}
// ProtocolCodecFilter will adapt ByteBufferCodecFactory
// into ProtocolCodecFactory.
ProtocolCodecFilter filter = new ProtocolCodecFilter(new MyCodecFactory());
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
