mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] Which filters should we keep ?
Date Sun, 10 Jan 2010 14:08:00 GMT

On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:

> Alan D. Cabrera a écrit :
>> On Jan 8, 2010, at 6:03 AM, Emmanuel Lecharny wrote:
>>> o SslFilter : I really think it shuld not be a filter, but a part  
>>> of the network layer. You negociate SSL first, then you accept  
>>> incoming messages.
>> I know that I am interested in receiving events such as SSL  
>> handshake started, completed, renegotiation, etc.  Why do you think  
>> that it needs to be part of the network layer?
> Being able to receive such notification is not related to the fact  
> that the SSL handling is done in Filters. To me, SSL handshaking on  
> NIO should have been a part of NIO, as it was a part of the standard  
> IO API. I don't see the rational behind this choice, but I see no  
> reason to inflict our users with such a problem like what they get  
> if they put the SSLFilter at the wrong place in the chain.

Filters convert messages as they pass up and down the stack.  SSL is  
no different.  I don't think that it's an undue burden to expect a  
certain level of competency so as to require that they know where to  
place filters in their stacks.

To my mind, SSL is a filter just as much as anything else, e.g. POJO<- 
 >JSON filter.  It seems to be that we arbitrarily culling out SSL and  
thereby loosing the consistency in our filter classifications.

IMO, Mina suffers from this problem and the number of different kinds  
of classes demonstrates it.

> Now, when it comes to the cases where you want to be informed about  
> renegotiation, or simply that you are on a secured connection, I  
> must say that I overlooked this point when I posted my other mail  
> about the message I want to remove : the "SECURED" one. We can't  
> remove this message from MINA 2.0, as it will negatively impact our  
> users who has based their handlers or codec on the assomption that  
> the very first received message will be this one.
> For MINA 3.0, I think we should get rid of it. Either we implement a  
> notification mechanism (à la Servlet), or - better IMHO - we can  
> also add a new event like notificationReceived() for such a use  
> case. Notification could cover all the SSL things, or any other we  
> can think about.

I assume that you are speaking of notification via listener  
interfaces.  I like that.  I hope that we don't end up with a swiss  
army knife of a listener; not that I hear that on this list but just  
expressing a general concern.


View raw message