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 ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
