directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <>
Subject RE: [mina] IoFilters: DIRMINA-121 / 122
Date Mon, 14 Nov 2005 21:56:32 GMT
Niklas Therning wrote:

> Yes that's the reason. But I'm not sure exactly what happens when 
> the last filter of a filter chain has been executed and control should

> be transferred to a new chain. The thing is that the code starting the

> filtering through a chain also has to know what should happen after
> chain has completed and create/use the appropriate handler.

> One possiblity would be to create chains of chains by wrapping them
two by two. 
> Let's pretend we have this special IoFilterChain implementation which
> two IoFilterChains (X, Y) and filters through them in order.
>We can use this implementation to combine an arbitrary number of 
> chains, (((A, B), C), D). Oh, how I love recursion! :)

This is what I was getting at in the last bit of my post (sorry - I read
it back and it didn't make much sense to me either - really shouldn't do
these 14 hour days :o)

I was thinking that chaining chains directly (as you describe above)
might be cleaner than having a chain masquerade as a handler.

So Im thinking that maybe the "ChainedFilterChain" or what-ever might be
a good way.

> The head and tail should not be needed anymore. 
> The Upstream/DownstreamNextFilters will know what to do when there are
no more filters.

As I understand it though, they will currently either delegate to the
IoHandler or to the IoProcessor.
And I think that's why you passed the handler through (so the next chain
can masquerade as a handler).
But I think we're maybe agreeing that a "ChainedFilterChain" is maybe a
cleaner approach (presumably to chain the per acceptor / connector chain
with the per session chain?).
So, given that: 

>> That way, you'd just have something like 
>> IoFilterChain#chain(IoFilterChain next). Any special meaning to the 
>> tail operations would be at a higher level.
>> (Again, clear in my head - but that doesn't mean anything :o)

> That doesn't make sense in my head! :) Though I am a bit sleepy at the
moment. Please elaborate.

That's my dumb way of saying that Im wondering whether the chain
implementation ** itself ** should even know or care about the "final
tasks" (i.e: Performing operations on the IoHandler or the IoProcessor).
If the chain just invokes filters until there are no more filters, then
the chain interface (and implementation) is pretty simple - and it
becomes very easy to "chain chains" using the "ChainedFilterChain" I
alluded to and you described.

Then there are endless possibilities to how filters and chains could be
attached together.
For example, you could even have IoFilterChain implement (directly, or
via adaptor) IoFilter.
Then you might have something real simple like this:

BasicFilterChain chain = ... // some basic impl - like
AbstractFilterChain is now
IoFilter sessionManagerFilter = ... // really a filter chain!
IoFilter sessionFilter = .... // really a filter chain!

// Dummy name: This is the filter that delegates to IoHandler,
EndOfTheLineFilter endOfTheLineFilter = ... 


This should also fit in with the DI stuff too.
I hope this makes a little more sense. But if it doesn't - I can
certainly discuss further when Im more awake :o)
(Been working since 7am, and its 10pm now - so Im more than a little
drained :o)

Any comments would be greatly appreciated....

> /Niklas



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