directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <dave.irv...@logicacmg.com>
Subject RE: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)
Date Tue, 15 Nov 2005 13:36:12 GMT

 
>> It kind of boils down to a few points:
>> 
>> 1) We want to chain "sequences" of filters (a filter chain) together

> Ok, why is it that we want to do this? What is it that we are trying
to solve?

One motivation is that concrete chain implementations currently specify
"end of chain" behaviour (e.g: SocketSessionManagerFilterChain,
DatagramSessionManagerFilterChain etc).
When we were originally looking at implementing 121 / 122, Niklas
suggested that it would be nice to refactor this - and I agree - as it
makes it more difficult to chain arbitrary filter chains in to longer
chains.
By doing the refactor, the "special" operations (currently provided by
SocketSessionManagerFilterChain et al) are provided by composition -
leaving a single basic chain implementation.

> Well, you could define today your own filter that encapsulates a
filter chain inside and that does this propagation. 
> The only thing you cannot do with such an arrangement is modify the
encapsulated chain from outside 
> (unless you know is being encapsulated and make the corresponding
calls on the encapsulating filter).

> public class EncapsulatedChainFilter(IoFilterChain chain) {
>	// Implementation delegates all methods to the chain and the
head and tail use the 
>     // nextfilter object to connect up or down as required.
> }

There is then a "NextFilter" problem. Each filter must be able to cache
its NextFilter to enable event propogation asyncronously. Say we used
the EncapsulatedChainFilter to hook together the sessionManager, port
and session chains for a connection. The problem would be that when the
last filter in, say, the port chain completed, we wouldn't be able to
route to the correct next filter chain (as sessionManager / port chains
are reused across connections).
That's why I suggested "ConnectionChains" (or whatever) which
encapsulates several connection chains, and performs routing based on
the session (very cheap using a Session attribute). (ConnectionChains
stuff is all behind the scenes).

What I think we end up with is a simple way to combine arbitrary chains
without requiring explicit subclassing for each use case.


> Jose Alberto

Dave


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.

Mime
View raw message