One other benefit to splitting it into two chains is it clarifies the order for a user. I only started using Mina a couple months ago, and one of the first things I got tripped over was the order the filters were called when a message was received vs. sent. My initial code had the filters in the reverse order of what they should be, because it wasn't clear which order they'd be called in for each case (not even in the documentation!) Splitting it into two chains would solve this issue completely.
Also, I'd like to make a plug for removing messageSent() callbacks and having the end-user API rely on WriteFutures instead. It's a hassle to write new filters when you have to worry about passing back the correct object. Oh, and one thing to keep in mind, whether or not filter chains are split into two, is that there are some filters that requires messages to be sent in the opposite direction currently, i.e. the SSLFilter. Looking through the SSLFilter, a lot of extra hidden complexity is created when the filter has to store references to the next filter in the chain so it can send the SSL protocol messages in response; this also breaks the ability for filter chains to be modified correctly (usually not a problem with SSLFilter, but could be with other filters). I'm not sure how this would work with a split filter chain, but there needs to be an API to automatically inject messages at specific points in the filter chain and bypass other filters (such as the protocol filter) so that multiple-level protocols, such as SSL wrapping, can be handled better. On Thu, Oct 30, 2008 at 6:28 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > > Proposition (a) : Let's create two chains instead of one : a > reader-chain/incoming-chain and a writer-chain/outgoing-chain.
