On 8/18/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> 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?
I added the following classes:
* org.apache.mina.common.DummySession
* org.apache.mina.filter.codec.ProtocolCodecSession (extends DummySession)
Using the two classes, I was able to remove a lot of code duplication
(i.e. anonymous dummy IoSession classes).
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
