mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@gmail.com>
Subject Re: [MINA 3] codec api
Date Wed, 06 Feb 2013 20:03:51 GMT
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 <jvermillard@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 <elecharny@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
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message