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