we should think of a codec as an independant module : it should be
available for any java code that just needs suh a codec for its own purpose.

such a need has already been expressed for http.

imo, the current impl is over-ingeniered.

Btw, it seems that we are up and running at 9am on jan. first... crazy open
source developpers...

happy new year !

Le 1 janv. 2013 09:26, "Julien Vermillard" <jvermill...@gmail.com> a écrit :
>
> It's sure 10 year after SEDA is quite smelly :-)
> In my mind the codec code should be used by a filter for transforming the
> bytes into pojos (like today) but really not dependent of MINA.
> IMHO demux handler is a piece of s..t, you should use a visitor pattern.
> Much more testable.
>
> I like the loop until it's decoded idea, it very simple to understand.
>  Le 31 déc. 2012 18:13, "Emmanuel Lécharny" <elecha...@gmail.com> a écrit
:
>
> > Le 12/31/12 7:55 AM, Julien Vermillard a écrit :
> > > Hi,
> > >
> > > Since few year, I stopped to use the MINA ProtocolCodecFilter and
> > > associated stuff (CumulativeCodec..). for implementing my own codec
> > > independent of MINA.
> > >
> > > it's just a service consuming ByteBuffer and pushing decoded POJO in a
> > > callback. The point is to be independent of MINA for example, parse &
> > save
> > > files using the codec, or simply implement an HTTP version of the
> > transport
> > > using old style servlet.
> > >
> > > Basically a decoder looks like : https://gist.github.com/4417934
> > > One is instantiated by session.
> > >
> > > I'm quite happy with that and I think we should not port the old
> > > ProtocolCodeFilter to MINA 3.0 and replace it with a independent MINA
> > async
> > > decoder framework (consuming BB, accumulating if needed and producing
> > pojo).
> > It sounds a reasonnable proposal.
> >
> > If we think about it, decoding is not part of a filter chain : it
> > introduces a change of data type being passed from one filter to the
> > other, and if we have to cumulate data, we will just stop processing the
> > incomming data in the middle of the chain, the handler being unaware of
> > this fact.
> >
> >
> > Julien's proposal seems way better : the Handler would have a common
> > interface for encoding and decoding, used as a service when a
> > MessageReceived or a Write events are to be processed. This way, the
> > handler is fully in charge of all the aspects of the data processing,
> > including the accumulation of data.
> >
> > It won't either eliminate the existence of pre-written codec, like the
> > HttpCodec, or the Textline codec. We can even think about a chain of
> > codecs : one codec depends on the result of the previous codec.
> >
> > As far as I can tell, changing MINA this way will not impact ApacheDS,
> > even if we are using a DemuxIoHandler (the handler called depends on the
> > received message) : I don't see such a handler as a simplification over
> > a simple switch...
> >
> >
> > Keep in mind that the exisiting MINA logic depends on an idea which is
> > 10 years old : SEDA, and has not proven any advantage against simpler
> > implementations. It's also important to notice that SEDA implies that
> > each process part communicates with the next process (read : filter) by
> > the use of queues. This is highly costly and memory consuming. I'm not
> > sure that SEDA has anything to do with MINA implementation anwyay...
> >
> > On more thing : the current codec supposes that we pass a callback which
> > is called as soon as something has been decoded. This make the code
> > extremely complicated to debug. I'd rather have a system where we can
> > loop on the decoder, until it produces nothing. In other words, instead
> > of having something like :
> >
> > void myCallback( IoSession session, Object message ) {
> >     // Do something
> > }
> >
> > void decode( IoSession session, ByteBuffer buffer, callback ) {
> >     // Decode and call the callback
> > }
> >
> >
> > void messageReceived( IoSession session, ByteBuffer buffer ) {
> >     decode( session, myCalback );
> >     ...
> > }
> >
> >
> > I would prefer something like :
> >
> > Object decode( IoSession session, ByteBuffer buffer ) {
> >     // Decode
> >
> >     return decoded;
> > }
> >
> >
> > void messageReceived( IoSession session, ByteBuffer buffer ) {
> >     while ( ( Object decoded = decode( session ) ) != null ) {
> >         // Do something
> >     }
> > }
> >
> >
> >
> >
> > >
> > > Julien
> > >
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
> >

Reply via email to