You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Ashish <pa...@gmail.com> on 2013/05/05 07:11:53 UTC
[3.0] Would we need CumulativeProtocolDecoder?
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).
Do we plan to introduce it 3.0?
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [3.0] Would we need CumulativeProtocolDecoder?
Posted by Ashish <pa...@gmail.com>.
On Sun, May 5, 2013 at 11:43 AM, Emmanuel Lécharny <el...@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
Re: [3.0] Would we need CumulativeProtocolDecoder?
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
Re: [3.0] Would we need CumulativeProtocolDecoder?
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/5/13 11:13 AM, Julien Vermillard a écrit :
> Hi Ashish !
>
>
> Do we plan to introduce it 3.0?
>
> I first coded one, but after thinking twice, I start to agree with
> Emmanuel here. We should provide facilities for the different use case
> :
> TLV, pattern matching termination, fixed length accumulation and for
> the more complex use case : IO buffer composite for doing it in your
> buffer.
>
> My main issue is compatibility. I think a lot of MINA 2 base code is
> using the CumulativeProtocolDecoder.
As MINA 3.0 will not use a filter for the codec, anyway, the
compatibility is not any more guaranteed.
Last time I did the migration from Mina 1.0 to MINA 2.0 on ApacheDS, I
had to ditch all th MINA 1 related code. It took me one day to get it
working with MINA 2, which is quite short if you consider the complexity
of the code (we use MINA for LDAP, Kerberos, DHCP, DNS, NTP...)
I would not be too concerned about that as soon as we have a decent
documentation for MINA 3 (and looking back to what we offered in MINA 1
and 2, that would be a great change !).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [3.0] Would we need CumulativeProtocolDecoder?
Posted by Julien Vermillard <jv...@gmail.com>.
Hi Ashish !
On Sun, May 5, 2013 at 7:11 AM, Ashish <pa...@gmail.com> wrote:
> 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).
IMO it's a mistake, we should use the IoBuffer Emmanuel coded : it's a
byte buffer accumulator.
The one in Http decoder is quite stupid, it's copying bytebuffer.
>
> Do we plan to introduce it 3.0?
>
I first coded one, but after thinking twice, I start to agree with
Emmanuel here. We should provide facilities for the different use case
:
TLV, pattern matching termination, fixed length accumulation and for
the more complex use case : IO buffer composite for doing it in your
buffer.
My main issue is compatibility. I think a lot of MINA 2 base code is
using the CumulativeProtocolDecoder.
Julien