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 12:36:11 GMT
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.
 
> 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:trustin@gmail.com] 
Sent: 15 November 2005 12:18
To: Apache Directory Developers List
Subject: Re: [mina] Refactoring MINA IoFilterChain (Was: IoFilters:
DIRMINA-121 / 122)


Hi Dave,

I started to like your suggestion, and I'd like to see its realization.
:)


2005/11/15, Irving, Dave <dave.irving@logicacmg.com >: 

	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.

Mime
View raw message