Hi Trustin,
Im really sorry if anything I said came accross like I was
critisising the current implementation. I certainly didn't mean it do
:o)
I was simply searching for a clean way to enable 121 and
122 to get solved in a clean way - and it seemed that refactoring the existing
chain mechanics might be a reasonable way to do that.
Thanks for your comments - I'll try and address them
here:
> I
started to like your suggestion, and I'd like to see its realization.
:)
I'll start working on it in earnest :o) Hopefully I'll be
able to report back with a patch in the next few days.
>> When the last
filter of a sub-chain is invoked, ConnectionChains does a
>> ( O(1) ) look up for the correct ConnectionChain based on session and
>> delegates.
>> ( O(1) ) look up for the correct ConnectionChain based on session and
>> delegates.
> Good
idea. Perhaps we can use session attributes here?
Session attributes are definately the best way to go here.
It means we dont need to hold a mapping within ConnectionChains - and we dont
need additional syncronization. I hadn't yet thought about how I'd implement the
mapping efficiently - so this suggestion is really very very useful to me.
Thanks!!!
> BTW J-F once asked us about emitting an event
virtually (not a real I/O event but fabricated one).
> I guess we can support this in our ConnectionChain by
exposing event emitting methods like I did in AbstractIoFilterChain?
Sure!
Have an IoEventProcessor
interface or some-such. The ConnectionChains (or whatever) can implement this (
- to kick off traversal like AbstractIoFilterChain does).
This can then be exposed to the user (without having to
expose the connection chain - which would be dangerous for obvious
reasons).
E.g:
IoEventProcessor processor =
somthing.getEventProcessor();
processor.messageReceived(session, message);
Viola - virtual Io events propogating right through the
correct connection chain :o)
Dave
From: Trustin Lee [mailto:[EMAIL PROTECTED]
Sent: 15 November 2005 12:18
To: Apache Directory Developers List
Subject: Re: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)
I started to like your suggestion, and I'd like to see its realization. :)
2005/11/15, Irving, Dave <[EMAIL PROTECTED]
>:
Good idea. Perhaps we can use session attributes here?
Sounds cool.
BTW J-F once asked us about emitting an event virtually (not a real I/O event but fabricated one). I guess we can support this in our ConnectionChain by exposing event emitting methods like I did in AbstractIoFilterChain?
Cheers,
Trustin
-- So why don't we just dispatch based on IoSession??
I.e, we have something like a "ConnectionChains" class which holds all
chains - mapped against IoSessions.
The final filter of a sub-chain (sessionManager chain, port chain,
session chain) is set by ConnectionChains to some private inner class.
When the last filter of a sub-chain is invoked, ConnectionChains does a
( O(1) ) look up for the correct ConnectionChain based on session and
delegates.
Good idea. Perhaps we can use session attributes here?
This allows us to get all the benefits previously discussed and solves
the NextFilter problem (including completely asyncronous calls to
NextFilter) without requiring cloning (which could be costly for some
filters).
How does that sound?
Sounds cool.
BTW J-F once asked us about emitting an event virtually (not a real I/O event but fabricated one). I guess we can support this in our ConnectionChain by exposing event emitting methods like I did in AbstractIoFilterChain?
Cheers,
Trustin
what we call human nature is actually human habit
--
http://gleamynode.net/
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.
