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