directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <>
Subject RE: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)
Date Tue, 15 Nov 2005 09:41:10 GMT

>  Explicitly asking users to add head/tail filter is a bad idea.   
I agree. In fact - thats my point :o)
>  But I think it is a great idea.  But we don't need to make a chain be
nested more than one level.   
>  And head and tail filter must be hidden from user to prevent from
unexpected removal or reordering. 
Exactly. The ** user ** doesn't write the code above: This is in the
acceptor (or whatever).
The idea is that the user can contribute a chain (Jose's approach) how
ever they like.
The special "head tail" behaviour is encapsulated to the client who
requires it: I.e, the acceptor / connector.
This is what I like about the idea. Currently, if you write a filter
chain, you need to care about that special head tail behaviour. Using
this approach you wouldn't - because a chain is nothing more than a
sequence of filters.
Its the acceptor / connector who cares about the head / tail behaviour -
so he can specify it directly.
Hopefully this example will clear up the creational logic:
Imagine this code is in SocketAcceptorDelegate.Worker#processSessions -
when we've just found out we've got a new session:
// Create the filter chain for the new connection / session
BasicFilterChain connectionChain = new BasicFilterChain();   
// Add the session manager chain to the connection chain
// Add the per-port chain to the connection chain 
// Let the user contribute to a new per-session chain (Jose's approach)
BasicFilterChain sessionChain = new BasicFilterChain();  
// Add the per-session filter to the connection chain
// Now create the filter which does ** our ** work (i.e, real handler
IoFilter workerFilter = new EndOfTheLineFilter(); 
connectionChain.add( workerFilter );
Notice that the user isn't specifying the worker filter - the
SocketAcceptorDelegate is.
So I belive this gives us real benefits:
1) Makes the filter chain mechanism simpler (reduces complexity as we're
now using composition rather than inheritance)
2) Paves the way for user contribution to chains (Jose's approach)
3) Doesn't require filter cloning or per-traversal clones
4) Is OO: The acceptor / connector is the actor who wants to specify
"end of chain" behaviour: So he does so by means of adding a custom
filter to the end of the built chain
Does this clear it up at all?
What do you think about this approach?
Many thanks,
Dave (give me sleep) Irving

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.

View raw message