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 <[email protected]>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 > <[email protected]>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 >> <[email protected]>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 >>> >>> >> >
