On 6/10/06, Niklas Therning <[EMAIL PROTECTED]> wrote:
Trustin Lee wrote: > The separation between IoHandler and protocol codec loses its meaning if > IoHandler takes care of the codec's state. That's why I don't want > IoHandler affect any state of decoder or encoder. And as I mentioned, the > state of the decoder might not change immediately in case that there's a > thread pool filter between the protocolcodecfilter and IoHandler. When the client sends the DATA command I do the following in my IoHandler: session.setAttribute(CommandProtocolDecoder.DATA_MODE); session.write(new OkResponse()); From here on my CommandProtocolDecoder will forward the received ByteBuffers without doing any special processing. Now consider what would happen if the IoHandler responds with a negative response instead. In that case my CommandProtocolDecoder shouldn't switch to data mode but should continue to decode as usual. If I'm not allowed to control this from my IoHandler my decoder and encoder would both have to be aware of (at least partially) where in the protocol flow the current session is. Of course my IoHandler also needs to now this so instead of my IoHandler being the only one with any knowledge of where we are in the flow all of them have to keep track of what has happened previously in order to know what to do next.
You are correct. Sorry for stating a wrong point.
My suggestion is still to provide a switchable encoder/decoder. > TokenSelectorStream in ANTLR shows a nice example regarding this pattern: > > http://www.antlr.org/doc/streams.html#lexerstates > > For example: > > SwitchableProtocolDecoder d = new SwitchableProtocolDecoder(); > d.register("default", new DefaultProtocolDecoder()); > d.register("attachment", new AttachmentDecoder()); > d.push("default"); > > ... > if (timeToDecodeAttachment) d.push("attachment"); > ... > if (finishedDecodingAttachment) d.pop(); > ... I think this is a very nice idea. Would my IoHandler control the pushes and pops? In that case you would still need the flush() method in PDO, right? Otherwise you cannot switch decoder in between two messages if they arrive in the same buffer. And the issue with using a ThreadPoolFilter between the ProtocolCodecFilter and IoHandler would still remain. Or am I missing something?
You're right. This selector pattern is not necessarilly related with the issue you raised. It is just a good-to-have class. Please remember that the only change to MINA I'm suggesting is to
introduce the flush() method in PDO so that I could control flushes from within my decoder. The PDO doesn't even have to be pluggable.
Ahh didn't we have a flush() method in ProtocolDecoderOutput? Let's add it then! :) Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
