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: About SslFilter.SESSION_SECURED
Date Sun, 10 Jan 2010 14:42:51 GMT

On Jan 10, 2010, at 6:19 AM, Emmanuel LŽcharny wrote:

> 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 4:05 PM, Emmanuel Lecharny wrote:
>>>>> Hi,
>>>>> while checking the SSL code, I found that we are injecting a  
>>>>> SslFilter.SESSION_SECURED message if some  
>>>>> SslFilter.USE_NOTIFICATION is true. This is just a String  
>>>>> ("SESSION_SECURED"), and it's used nowhere.
>>>>> If nobody can tell me about how usefull it is, I will remove all  
>>>>> this garbage. (IMO, this has been added a *long* time ago, back  
>>>>> in oct 2005, but it's not anymore necessary now. I don't even  
>>>>> understand what it was good for back then...).
>>>> I was talking to someone about this pattern in message stacks and  
>>>> think that it's an anti-pattern.  We debated for a while and I  
>>>> think my point was taken with some reservations.  Let me  
>>>> elaborate on this anti-pattern and why it's bad.
>>>> To my mind there are two ways to communicate events and  
>>>> orchestrate behavior in this world of ours.  First is using  
>>>> interfaces to connect listeners with broadcasters.  The other is  
>>>> by sending actual "known" message objects up and down the message  
>>>> stack.  I believe that the latter is an anti-pattern since it  
>>>> forces everyone to participate in the dispatching of the events,  
>>>> most of whom one doesn't care about, and when there is an event  
>>>> that is interesting in reality it is an event that's really part  
>>>> of a lifecycle which, imo, should be an interface.  The pattern  
>>>> is also brittle in that if relies on flawless execution by all  
>>>> members of the stack.
>>>> The example of a need to send messages up the stack was the idle  
>>>> event.  IMO, this should not be in a library since it's an  
>>>> application specific notion and it's quite possible that  
>>>> participants in the stack may have a different notion as to what  
>>>> constitutes an idle state.
>>>> Maybe there are other examples where this pattern is compelling  
>>>> but I cannot think of any.
>>> I partly agree with you. However, I see how a Filter can benefit  
>>> from being informed about a specific message, such as the  
>>> 'secured' one.
>> Can you give a concrete example?  Usually that would be a  
>> communication between to connected filters not a general  
>> notification to the entire stack.
> The problem is that filters don't necessary know that the filter  
> they want to communicate with is present in the chain. A  
> notification mechanism is much better, as the filter which need to  
> be informed about a notification just have to be subscribed to such  
> a notification (or to implement the method to catch this  
> notification).
> A concrete exemple in our case (SslFilter) would be for the  
> application to be able to know that the session is secured. I woudl  
> not like my application to send a private key on he clear, or any  
> private data, over a clear connection, for instance ! Of course, I  
> can check if the session is secured in another way (pulling the info  
> from the session attributes) but I don't think that it's a bad idea  
> to send a specific message to the handler.

I'm hearing an application specific example, not an example where the  
entire protocol stack needs to participate.

>>> However (and you can check on another mail I wrote) I think that  
>>> we may need to add a specific event for such a case, a  
>>> notificationReceived() (and may be a notificationSend() :  this  
>>> could be used to inform the IoProcessor that the current session  
>>> should be closed)
>> Sorry, I'm not following, can you give a concrete example of what  
>> you're thinking about?
> Right now, we just handle a few kind of events, like  
> MessageReceived, MessageSent, SessionClosed, ExceptionCaught. I  
> think that a notification like 'SessionSecured' could be valuable,  
> instead of sending a String containing 'SECURED' in a  
> MessageReceived event.
> Does it make sense ?

Ahh, ok, so "notificationReceived" is a generic notification.

Is MessageReceived, MessageSent in general use?  It seems that they  
would be but those events strike me as very application specific and  
not cross cutting such as SessionClosed.  For example, I could imagine  
that for one message sent from the top of the stack many get created  
downstream.  So, with that in mind, Message sent/received really only  
pertains to the top filter.  It would be interesting to see if there  
are counter examples.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message