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/01/28 21:00:44 UTC
[MINA 3] codec api
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
- a codec in compounded of a statefull decoder and an encoder
- each session will store a encoder and a decoder
I updated the HTTP codec but not the LDAP codec. I need to take care of
make it compiling soon.
Anyway I would like quick feedback on the code for knowing if we could keep
it, so I could finish it (doc, adapting TextLineCodec and adding
accumulation facilities).
Julien
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
>>
>>
>
Re: [MINA 3] codec api
Posted by Julien Vermillard <jv...@gmail.com>.
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 Emmanuel Lécharny <el...@gmail.com>.
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 Emmanuel Lécharny <el...@gmail.com>.
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.
>
> I updated the HTTP codec but not the LDAP codec. I need to take care of
> make it compiling soon.
Forget about the ldap codec. It has to be completely refactored anyway.
I'll do it.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com