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. > 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? 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. -- Niklas Therning Software Architect www.spamdrain.net
