mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [About the Filter Chain] Proposals
Date Sat, 01 Nov 2008 00:51:11 GMT
Squee wrote:
> One other benefit to splitting it into two chains is it clarifies the
> order for a user. 
Absolutely. This is onbe of my major concern with the current code. It 
takes forever to get on grip on it, and when it comes to debugging it, 
it's like you are a mouse trapped in a maze...
> 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.
I'm still puzzled with the path messages are supposed to follow to be 
frank ;)
>  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.
I hope so !
> 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.
We are alsoi discussion about removing this MessageSent event which is, 
IMHO totally useless, and also a source of confusion. (So is the 
SessionCreated vs SessionOpened...)
> 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.
I had a quick look at the SSL filter. I'm not really confortable with 
its code, as I just had a quick glance at it. The confusion might be 
that we need to do some handshake with the client, exchanging some 
messages back and forth with the client. This could certainly be 
resolved by defining two chains : one for the handshake, and the other 
for the protocol the client is implementing. Switching from one to the 
other is not really complicated. (FYI, we already do that in LDAP)
> 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.
We have to work on this, that's for sure.

Thanks for pointing this out. We have to remember to reviex all the 
existing filters with respect to the suggested modification, obviously.

And, btw, any help is welcome !

Thanks :)

cordialement, regards,
Emmanuel L├ęcharny

View raw message