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
www.iktek.com
directory.apache.org
