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 >> >> >
