mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel LŽcharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Which filters should we keep ?
Date Sun, 10 Jan 2010 14:22:59 GMT
Alan D. Cabrera a écrit :
> 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.
I'm plain wrong here. I realized that it's not because the SslFilter is 
conveying encrypted data that you won't do anything *before*. For 
instance, one may perfectly want to inject an Executor filter to spread 
the wrap/unwrap load onto many threads. In this case, having the 
SslFilter is a good thing.

Forget about my suggestion, it was illy.
>> 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.
More or less. We can discuss this aspect on another thread, for clarity.

View raw message