Hi, I wanted to sleep, by my son wasn't agreeing :) I will probably crash later.
Yeah we could experiment with the HTTP codec, it's in pretty bad state for now. It would be nice to be able to share the codec code between MINA 2 and 3. Julien On Tue, Jan 1, 2013 at 9:45 AM, Emmanuel Lecharny <[email protected]>wrote: > 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" <[email protected]> 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" <[email protected]> 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 > > > > > > >
