directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niklas Therning" <nik...@trillian.se>
Subject RE: [mina] IoFilters: DIRMINA-121 / 122
Date Mon, 14 Nov 2005 14:52:05 GMT
Hi Dave,

I have some thoughts on DIRMINA-121. It would be nice if there wouldn't have
to be specialized IoFilterChain implementations for each kind of
Acceptor/Connector. Today we have SocketSessionManagerFilterChain,
DatagramSessionManagerFilterChain, and so on. This makes it hard to combine
arbitrary IoFilterChains into longer chains which is required for
DIRMINA-121.

Here's my suggestion on how to achieve this:

Add a new interface which is the counter part of IoHandler. I don't have a
good name for it, let's call it IoProcessor for now. IoProcessor looks
something like this:

public interface IoProcessor {
    void write( IoSession session, WriteRequest writeRequest );
    void close( IoSession session, CloseFuture closeFuture );
}

Add some methods to the IoFilterChain interface:

void setIoProcessor( IoProcessor p );

void sessionOpened( IoSession session, IoHandler h ) throws Exception;
void sessionClosed( IoSession session, IoHandler h ) throws Exception;
void messageReceived( IoSession session, Object message, IoHandler h )
throws Exception;
... (I think you get the point)

These are exactly the same as the methods in IoHandler except that the extra
IoHandler argument has been added. The idea is that this should be
propagated through the chain (embedded in the NextFilter class). The tail
filter in a chain will always get the IoHandler from the NextFilter and call
it. When combining IoFilterChains A and B, B is the IoHandler of A while the
real IoHandler is the IoHandler of B.

The nice thing about this is that you can combine an arbitrary number of
IoFilterChains. It also makes it possible to have a setFilterChain() method
on SocketAcceptor and other SessionManagers which make these more
DI-friendly. When using setFilterChain() on an IoAcceptor the acceptor will
call setIoProcessor() on the filter chain.

When you call bind(address, chain, handler) the setIoProcessor() method of
the chain will be called to wire it up with the root filter chain owned by
the IoAcceptor/IoConnector.

I don't think it will require any refactoring of existing filters. It will
also eliminate a couple of interface/classes (like the
SessionManagerFilterChains).

Let me know what you think.

/Niklas

-----Original Message-----
From: Irving, Dave [mailto:dave.irving@logicacmg.com] 
Sent: den 14 november 2005 14:18
To: Apache Directory Developers List
Subject: [mina] IoFilters: DIRMINA-121 / 122

Hi,

It looks like Im going to need to get DIRMINA-121 completed before I can
tackle DIRMINA-116.
It also looks like 121 is closely related to 122. Is anyone working on
these at the moment?
If not, I don't mind picking them up - I can probably spend a few hours
beginning to look at it tonight after work.

If that's agreed on - has the factory vs builder route been decided on
yet? (The builder approach looks cleaner to me?).

Any comments / preferences / etc appreciated....

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