You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Julien Vermillard <jv...@gmail.com> on 2013/02/03 16:25:49 UTC
Re: [MINA 3] codec api
I was thinking about the codec in the handler and sometimes you want
filters after the codec ( example filter for generating access logs).
For stateless SM based decoder this enum based method could apply :
http://vanillajava.blogspot.fr/2011/06/java-secret-using-enum-as-state-machine.html
On Tue, Jan 29, 2013 at 2:12 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 1/29/13 1:20 PM, Emmanuel Lécharny a écrit :
> > Le 1/28/13 9:00 PM, Julien Vermillard a écrit :
> >> Hi,
> >> I committed a new idea for the codec API.
> >> It's quite radical change but I think it's a valuable improvement.
> >>
> >> Key here is simplicity :
> >> - a codec module independent of the core module, could be reused for
> mina
> >> 2, plain old IO, whatever
> > So far, so good.
> >> - a codec in compounded of a statefull decoder and an encoder
> > Does those encoder/decoder have to be stateful ? In some case, we may
> > wan to use a stateless decoder, because we don't want to store some
> > state into it.
> >
> > I'd rather let the user decide if his/her codec is stateless or stateful
> > (and handle the consequences).
> >
> > (I do think that most of the case, a stateless decoder is needed).
> >
> >> - each session will store a encoder and a decoder
> > If we use stateless decoder, there is no need to store the
> > encoder/decoder in the session, just to make them available. The way
> > it's currently done (pushing a reference to the encoder/decoder
> > instances into the session attributes) is costly, and memory consuming
> > (as you have to access the hashmap everytime you need to access the
> > codec, and you create a <ref, codec> in every session.
> >
> > I would rather default to something that store a reference in the
> > IoHandler, with the optional option to store the codec in the session.
> > The IoSession.getEncoder/Decoder() methods will handle different cases.
>
> Thinking a bit more about it, the fact that the codec is stateful or
> stateless is a bit irrelevant to this discussion.
>
> The real problem is more about how we access to the codec, and
> especially when we want to have more than one codec in the chain.
>
> We can have three possible use case here :
> - we want a stateless codec : it's just a matter of associate it with
> the IoHandler, up to the session to access it
> - we want a stateful codec : we instanciate a new codec in the
> sessionCreated() event, and it's stored in each session
> - we want more than one codec per session (stateful or stateless) : we
> have to ask the session to return the codec we want by using a
> getDecoder(<name>) in each filter.
>
> What would really help is to be able to stor ethe encoder/decoder in a
> Session field, instead of storing them in the Session's attributes.
> That's the real difference.
>
> Thoughts ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: [MINA 3] codec api
Posted by Julien Vermillard <jv...@gmail.com>.
Finally I found a bit of time for a new try :
https://git-wip-us.apache.org/repos/asf?p=mina.git;a=tree;f=codec/src/main/java/org/apache/mina/codec;h=bdd9419b66f3368bd693ff597e30f955fae2d5f9;hb=1a4ad866eb25e509a8eb4b5d52e4660152cc5ded
The encoder, decoder are immutable and a state is passer fior
encoding/decoding.
WDYT ?
Julien
On Wed, Feb 6, 2013 at 9:03 PM, Julien Vermillard <jv...@gmail.com>wrote:
> Thinking a bit more about the issue, A stateless system will fit both
> UDP/TCP with the same API. It's a bit less simple than the proposed
> stateful API but it's probably a good compromise.
>
> I'll try that
>
>
> On Sun, Feb 3, 2013 at 4:25 PM, Julien Vermillard <jv...@gmail.com>wrote:
>
>> I was thinking about the codec in the handler and sometimes you want
>> filters after the codec ( example filter for generating access logs).
>>
>> For stateless SM based decoder this enum based method could apply :
>> http://vanillajava.blogspot.fr/2011/06/java-secret-using-enum-as-state-machine.html
>>
>>
>> On Tue, Jan 29, 2013 at 2:12 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
>>
>>> Le 1/29/13 1:20 PM, Emmanuel Lécharny a écrit :
>>> > Le 1/28/13 9:00 PM, Julien Vermillard a écrit :
>>> >> Hi,
>>> >> I committed a new idea for the codec API.
>>> >> It's quite radical change but I think it's a valuable improvement.
>>> >>
>>> >> Key here is simplicity :
>>> >> - a codec module independent of the core module, could be reused for
>>> mina
>>> >> 2, plain old IO, whatever
>>> > So far, so good.
>>> >> - a codec in compounded of a statefull decoder and an encoder
>>> > Does those encoder/decoder have to be stateful ? In some case, we may
>>> > wan to use a stateless decoder, because we don't want to store some
>>> > state into it.
>>> >
>>> > I'd rather let the user decide if his/her codec is stateless or
>>> stateful
>>> > (and handle the consequences).
>>> >
>>> > (I do think that most of the case, a stateless decoder is needed).
>>> >
>>> >> - each session will store a encoder and a decoder
>>> > If we use stateless decoder, there is no need to store the
>>> > encoder/decoder in the session, just to make them available. The way
>>> > it's currently done (pushing a reference to the encoder/decoder
>>> > instances into the session attributes) is costly, and memory consuming
>>> > (as you have to access the hashmap everytime you need to access the
>>> > codec, and you create a <ref, codec> in every session.
>>> >
>>> > I would rather default to something that store a reference in the
>>> > IoHandler, with the optional option to store the codec in the session.
>>> > The IoSession.getEncoder/Decoder() methods will handle different cases.
>>>
>>> Thinking a bit more about it, the fact that the codec is stateful or
>>> stateless is a bit irrelevant to this discussion.
>>>
>>> The real problem is more about how we access to the codec, and
>>> especially when we want to have more than one codec in the chain.
>>>
>>> We can have three possible use case here :
>>> - we want a stateless codec : it's just a matter of associate it with
>>> the IoHandler, up to the session to access it
>>> - we want a stateful codec : we instanciate a new codec in the
>>> sessionCreated() event, and it's stored in each session
>>> - we want more than one codec per session (stateful or stateless) : we
>>> have to ask the session to return the codec we want by using a
>>> getDecoder(<name>) in each filter.
>>>
>>> What would really help is to be able to stor ethe encoder/decoder in a
>>> Session field, instead of storing them in the Session's attributes.
>>> That's the real difference.
>>>
>>> Thoughts ?
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>>
>>
>
Re: [MINA 3] codec api
Posted by Julien Vermillard <jv...@gmail.com>.
Thinking a bit more about the issue, A stateless system will fit both
UDP/TCP with the same API. It's a bit less simple than the proposed
stateful API but it's probably a good compromise.
I'll try that
On Sun, Feb 3, 2013 at 4:25 PM, Julien Vermillard <jv...@gmail.com>wrote:
> I was thinking about the codec in the handler and sometimes you want
> filters after the codec ( example filter for generating access logs).
>
> For stateless SM based decoder this enum based method could apply :
> http://vanillajava.blogspot.fr/2011/06/java-secret-using-enum-as-state-machine.html
>
>
> On Tue, Jan 29, 2013 at 2:12 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
>
>> Le 1/29/13 1:20 PM, Emmanuel Lécharny a écrit :
>> > Le 1/28/13 9:00 PM, Julien Vermillard a écrit :
>> >> Hi,
>> >> I committed a new idea for the codec API.
>> >> It's quite radical change but I think it's a valuable improvement.
>> >>
>> >> Key here is simplicity :
>> >> - a codec module independent of the core module, could be reused for
>> mina
>> >> 2, plain old IO, whatever
>> > So far, so good.
>> >> - a codec in compounded of a statefull decoder and an encoder
>> > Does those encoder/decoder have to be stateful ? In some case, we may
>> > wan to use a stateless decoder, because we don't want to store some
>> > state into it.
>> >
>> > I'd rather let the user decide if his/her codec is stateless or stateful
>> > (and handle the consequences).
>> >
>> > (I do think that most of the case, a stateless decoder is needed).
>> >
>> >> - each session will store a encoder and a decoder
>> > If we use stateless decoder, there is no need to store the
>> > encoder/decoder in the session, just to make them available. The way
>> > it's currently done (pushing a reference to the encoder/decoder
>> > instances into the session attributes) is costly, and memory consuming
>> > (as you have to access the hashmap everytime you need to access the
>> > codec, and you create a <ref, codec> in every session.
>> >
>> > I would rather default to something that store a reference in the
>> > IoHandler, with the optional option to store the codec in the session.
>> > The IoSession.getEncoder/Decoder() methods will handle different cases.
>>
>> Thinking a bit more about it, the fact that the codec is stateful or
>> stateless is a bit irrelevant to this discussion.
>>
>> The real problem is more about how we access to the codec, and
>> especially when we want to have more than one codec in the chain.
>>
>> We can have three possible use case here :
>> - we want a stateless codec : it's just a matter of associate it with
>> the IoHandler, up to the session to access it
>> - we want a stateful codec : we instanciate a new codec in the
>> sessionCreated() event, and it's stored in each session
>> - we want more than one codec per session (stateful or stateless) : we
>> have to ask the session to return the codec we want by using a
>> getDecoder(<name>) in each filter.
>>
>> What would really help is to be able to stor ethe encoder/decoder in a
>> Session field, instead of storing them in the Session's attributes.
>> That's the real difference.
>>
>> Thoughts ?
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>