On Sun, May 5, 2013 at 11:43 AM, Emmanuel Lécharny <elecha...@gmail.com>wrote:
> Le 5/5/13 7:11 AM, Ashish a écrit : > > Folks, > > > > I remember the discussion about not to have CumulativeProtocolDecoder in > > 3.0. IMHO, we have many scenarios where we would need it, otherwise we > > might end up writing our own context implementations to store partial > > messages (we have one in TextLineDecoder and Http Decoder has its own). > > I don't remember what we decided - I can't find the thread where we were > discussing this matter -. > > From the top of my head, there are two aspects : > > 1) where do we store the cumulated data : in one single ByteBuffer - > thus copying the newly read data into it - or in a list of ByteBuffer, > with an wrapper on top of this list ? > 2) what kind of rule do we apply on the limit ? > > The second aspect is quite simple. Currently, we can consider that we > have the following use cases : > - fixed size packet (the size is configured in the codec) > - size determinated by a character or a String (like a new line) > - size included in the packet (LV : Length/Value) > > I don't see any other use case atm. > > Regarding the first aspect, I do think that using a class that wrap a > list of ByteBuffer and mimic the ByteBuffer methods would help. I > actually pushed such a class in MINA 3, it's the IoBuffer class. > > I don't see any reason not to offer such a facility to the codec > writters. The question was more about where should we put such a codec. > We now think that the codec should not be a filter, but a standalone > system that could be used upfront by the application (see [MINA 3] codec > api discussion). > > Does it fits what you need ? > Yup it does. Once we have this facility we can easily handle all kinds of serliazation codecs, it would be easy to add support for Avro, msgpack, bson etc > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
