mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: [3.0] Would we need CumulativeProtocolDecoder?
Date Sun, 05 May 2013 06:13:54 GMT
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 ?

Emmanuel Lécharny

View raw message