On 8/18/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> 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());
I found a serious flaw in this design; we have to maintain two copies
of the effectively same out-of-the-box codec implementation (i.e. one
for ByteBufferCodecFactory and the other for ProtocolCodecFactory.) I
can't think of any good idea to take care of this issue.
One possible idea is to provide a ByteBufferSession, which can be used
as mock as well as a kind of buffer. ByteBufferSession could have
underlying input and output buffer that can be publicly accessible and
also could be created from an existing input buffer. By providing
this kind of multi-purpose session, we can satisfy both testers and
those who want incorporation with non-MINA apps. WDYT?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
