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 Sat, 09 Jan 2010 14:23:19 GMT

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.


View raw message