Taking a look now. Looks like the code is not really commented :( On Wed, Jan 2, 2013 at 12:08 PM, Ashish <paliwalash...@gmail.com> wrote:
> hc has nio based implementation as well > http://hc.apache.org/httpcomponents-core-ga/httpcore-nio/xref/index.html > See nio.codecs package > > > > > On Tue, Jan 1, 2013 at 11:53 PM, Julien Vermillard <jvermill...@gmail.com > >wrote: > > > Definitively should take a look. > > The only tricky issue is streaming large content, because MINA have an > > event based paradigm where H.C. have probably a stream based approach. > > > > Julien > > Le 1 janv. 2013 16:33, "Arnaud bourree" <arnaud.bour...@gmail.com> a > > écrit : > > > > > Hi, > > > > > > Happy new year 2013. > > > > > > I'm strongly interested in HTTP codec: I used for one project I did > > > for my company. > > > Here there are my point of view: > > > - share codec between MINA 2 and 3: I initially take MINA 3 as base to > > > implement on MINA 2 and keep classes and package structure. BTW share > > > should be easy to do, but when I did job, I made some change due to > > > JDK version 5 for MINA 2 and 6 for MINA 3 > > > - codec independent from MINA: I take a look on the web to find HTTP > > > API object to convert BB to, I find that Apache HTTP Client > > > (http-core) feet what we need. > > > What do you think to used http-core as API for Pojo object and write > > > HTTP codec to encode/decode BB from/to http-core objects and on top a > > > HTTP filter for MINA framework? > > > > > > Regrards, > > > > > > Arnaud. > > > > > > 2013/1/1 Julien Vermillard <jvermill...@gmail.com>: > > > > 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 < > > elecha...@apache.org > > > >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" <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 > > > >> > > > > > >> > > > > > >> > > > > > > > > > -- > thanks > ashish > > Blog: http://www.ashishpaliwal.com/blog > My Photo Galleries: http://www.pbase.com/ashishpaliwal >
