[mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)

[Trustin Lee]

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

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)

No problem.  I don't feel bad at all.  We're all here to make MINA the best network application framework as you know.  I think we can even beat ACE in the near future ;)

Cheers,
Trustin

--
what we call human nature is actually human habit
--
http://gleamynode.net/

[Jose Alberto Fernandez-2]

> From: Irving, Dave [mailto:dave.irving@...]
>
> It kind of boils down to a few points:
>
> 1) We want to chain "sequences" of filters (a filter chain) together

Ok, why is it that we want to do this? What is it that we are trying to
solve?

> 2) Why not make IoFilterChain move towards the composite pattern? A
> filter chain is just a special type of filter which filters in a
> sequence. No special head, no special tail. Just a sequence 0..n. So
> given some "BasicFilterChain" impl, we can add both individual filters
> and filter chains to the chain. NextFilters can ** still ** be cached
by
> individual filters - no change there.

Well, you could define today your own filter that encapsulates a filter
chain inside and that does this propagation. The only thing you cannot
do with such an arrangement is modify the encapsulated chain from
outside (unless you know is being encapsulated and make the
corresponding calls on the encapsulating filter).

public class EncapsulatedChainFilter(IoFilterChain chain) {
        // Implementation delegates all methods to the chain and the
head and tail use the nextfilter object to connect up or down as
required.
}

Jose Alberto

[Irving, Dave]

 
>> It kind of boils down to a few points:
>>
>> 1) We want to chain "sequences" of filters (a filter chain) together

> Ok, why is it that we want to do this? What is it that we are trying
to solve?

One motivation is that concrete chain implementations currently specify
"end of chain" behaviour (e.g: SocketSessionManagerFilterChain,
DatagramSessionManagerFilterChain etc).
When we were originally looking at implementing 121 / 122, Niklas
suggested that it would be nice to refactor this - and I agree - as it
makes it more difficult to chain arbitrary filter chains in to longer
chains.
By doing the refactor, the "special" operations (currently provided by
SocketSessionManagerFilterChain et al) are provided by composition -
leaving a single basic chain implementation.

> Well, you could define today your own filter that encapsulates a
filter chain inside and that does this propagation.
> The only thing you cannot do with such an arrangement is modify the
encapsulated chain from outside
> (unless you know is being encapsulated and make the corresponding
calls on the encapsulating filter).

> public class EncapsulatedChainFilter(IoFilterChain chain) {
> // Implementation delegates all methods to the chain and the
head and tail use the
>     // nextfilter object to connect up or down as required.
> }

There is then a "NextFilter" problem. Each filter must be able to cache
its NextFilter to enable event propogation asyncronously. Say we used
the EncapsulatedChainFilter to hook together the sessionManager, port
and session chains for a connection. The problem would be that when the
last filter in, say, the port chain completed, we wouldn't be able to
route to the correct next filter chain (as sessionManager / port chains
are reused across connections).
That's why I suggested "ConnectionChains" (or whatever) which
encapsulates several connection chains, and performs routing based on
the session (very cheap using a Session attribute). (ConnectionChains
stuff is all behind the scenes).

What I think we end up with is a simple way to combine arbitrary chains
without requiring explicit subclassing for each use case.


> Jose Alberto

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.

[Niklas Therning]

Jose Alberto Fernandez wrote:

>>From: Irving, Dave [mailto:dave.irving@...]
>>
>>It kind of boils down to a few points:
>>
>>1) We want to chain "sequences" of filters (a filter chain) together
>>    
>>
>
>Ok, why is it that we want to do this? What is it that we are trying to
>solve?
>  
>

Since I was the one who initially started the conversion about
port-specific chains let me explain what it is I want to do.

I have a POP3Handler which implements a POP3 server. I want to configure
this using Spring. Thanks to the Spring integration code which now is in
Mina I can do that.

Then we wanted to support SSL connections. Ideally the same POP3Handler
could be used and depending on the port an SSLFilter will be applied or
not. Since I'm still using Spring it would be very nice if I could
configure this without having to add any additional code to POP3Handler.
This isn't possible today since there are no port-specific filter chains
in Mina at the moment.

My current workaround involves code in POP3Handler which checks the
local address of a new connection in sessionCreated and if it is 995
(the POP3S port) an SSLFilter instance will be added to the session's
filter chain. I would like to do this in my Spring context XML file
without my POP3Handler having to know about it. It will reduce
complexity and POP3Handler could concentrate on what it is supposed to
do without having to worry about configuration. The workaround kind of
defeats one of the motivations behind using the DI-pattern in the first
place.

/Niklas

[Jose Alberto Fernandez-2]

> From: Irving, Dave [mailto:dave.irving@...]
>
>
> >> It kind of boils down to a few points:
> >>
> >> 1) We want to chain "sequences" of filters (a filter chain)
together
>
> > Ok, why is it that we want to do this? What is it that we are trying
> to solve?
>
> One motivation is that concrete chain implementations currently
specify
> "end of chain" behaviour (e.g: SocketSessionManagerFilterChain,
> DatagramSessionManagerFilterChain etc).
> When we were originally looking at implementing 121 / 122, Niklas
> suggested that it would be nice to refactor this - and I agree - as it
> makes it more difficult to chain arbitrary filter chains in to longer
> chains.

Why is it that we want to chain arbitrary filter chains into longer
chains?
It seems that the reason for the requirement is the requirement itself.
But what is the reason for it?

I may be mistaken, but it seems to me the whole reason for this is to be
able, eventually, to specify a chain in a spring based model and set it
up during configuration. Am I off the mark here?

Wouldn't it be simpler (or less disruptive) to simply configure some
other object (lets say a ChainBuilder) with all the filters one
requires, and during execution (the call to build) it will just add all
the filters to the chain programmatically. No need to re-engineer
everything just one smart spring aware builder.

Would this solve any of the user patterns we are trying to deal with in
here?

Jose Alberto

[Niklas Therning]

Jose Alberto Fernandez wrote:

>>From: Irving, Dave [mailto:dave.irving@...]
>>
>>
>>    
>>
>>>>It kind of boils down to a few points:
>>>>
>>>>1) We want to chain "sequences" of filters (a filter chain)
>>>>        
>>>>
>together
>  
>
>>>Ok, why is it that we want to do this? What is it that we are trying
>>>      
>>>
>>to solve?
>>
>>One motivation is that concrete chain implementations currently
>>    
>>
>specify
>  
>
>>"end of chain" behaviour (e.g: SocketSessionManagerFilterChain,
>>DatagramSessionManagerFilterChain etc).
>>When we were originally looking at implementing 121 / 122, Niklas
>>suggested that it would be nice to refactor this - and I agree - as it
>>makes it more difficult to chain arbitrary filter chains in to longer
>>chains.
>>    
>>
>
>Why is it that we want to chain arbitrary filter chains into longer
>chains?
>It seems that the reason for the requirement is the requirement itself.
>But what is the reason for it?
>
>I may be mistaken, but it seems to me the whole reason for this is to be
>able, eventually, to specify a chain in a spring based model and set it
>up during configuration. Am I off the mark here?
>
>Wouldn't it be simpler (or less disruptive) to simply configure some
>other object (lets say a ChainBuilder) with all the filters one
>requires, and during execution (the call to build) it will just add all
>the filters to the chain programmatically. No need to re-engineer
>everything just one smart spring aware builder.
>
>Would this solve any of the user patterns we are trying to deal with in
>here?
>
>  
>

I've actually thought of adding such a feature to the
AbstractIoAcceptorFactoryBean. I think it would require a proxy for the
real IoHandler which intercepts sessionCreated() and simply adds the
appropriate port-specific filters to the session's filter chain before
forwarding to the real IoHandler. It's not a bad idea at all and I might
do it that way in the meantime. Thanks for pointing that out! :)

But I also think that the refactoring Dave is working on will make the
code simpler to understand/maintain and give more flexibilty. Let's see
what he comes up with and take it from there.

/Niklas

[Irving, Dave]

 

> Why is it that we want to chain arbitrary filter chains into longer
chains?
> It seems that the reason for the requirement is the requirement
itself.
> But what is the reason for it?

As per Niklas' email, we'll need to support a combined sessionManager
chain, port chain and connection chain.
Is there a clean way to do this that I've missed? Im certainly not
interested in doing work for works sake :o)

> I may be mistaken, but it seems to me the whole reason for this is to
be able, eventually, to specify a chain
> in a spring based model and set it up during configuration. Am I off
the mark here?

I think the refactoring we are talking about is not related to spring
configuration per-se. In all cases, the three layers of chains will be
available to be populated by a builder or whatever. The problem we are
solving, as far as I can tell, is how to have re-usable chains of
filters (sessionManager, port, session) cleanly and efficiently (i.e,
not having to clone).

> Wouldn't it be simpler (or less disruptive) to simply configure some
other object (lets say a ChainBuilder)
> with all the filters one requires, and during execution (the call to
build) it will just add all the
> filters to the chain programmatically. No need to re-engineer
everything just one smart spring aware builder.

As above, the spring configuration is not the direct motivation for the
refactoring.

> Would this solve any of the user patterns we are trying to deal with
in here?

Niklas wants to specify re-usable port chains, and presumably its
helpful to be able to specify re-usable session manager level chains
(acceptor / connector). The problem to solve is how to cleanly hook
these chains together.
It seems that the proposed refactoring is quite a simple and transparent
way of doing this - but if I've missed an existing easy and clean way to
do this - please let me know - as I don't want to head down the wrong
path!

> Jose Alberto

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.

[Jose Alberto Fernandez-2]

> From: Niklas Therning [mailto:niklas@...]
>
> Jose Alberto Fernandez wrote:
>
> >I may be mistaken, but it seems to me the whole reason for this is to
be
> >able, eventually, to specify a chain in a spring based model and set
it
> >up during configuration. Am I off the mark here?
> >
> >Wouldn't it be simpler (or less disruptive) to simply configure some
> >other object (lets say a ChainBuilder) with all the filters one
> >requires, and during execution (the call to build) it will just add
all
> >the filters to the chain programmatically. No need to re-engineer
> >everything just one smart spring aware builder.
> >
> >Would this solve any of the user patterns we are trying to deal with
in
> >here?
> >
> >
> >
> I've actually thought of adding such a feature to the
> AbstractIoAcceptorFactoryBean. I think it would require a proxy for
the
> real IoHandler which intercepts sessionCreated() and simply adds the
> appropriate port-specific filters to the session's filter chain before
> forwarding to the real IoHandler. It's not a bad idea at all and I
might
> do it that way in the meantime. Thanks for pointing that out! :)
>

But remember the spirit of 121/122 is that you will have port level
filters.
The builder will configure the port level filters (which as I understand
today gets cloned when a session is created). So in this scenario you do
not need to play with sessionCreated or anything, the spring configured
builder will just apply the filters during binding and then the
IoHandler is free to do whatever it requires.

Now, in this model it is very simple to define composite builders since
they just need to call the build method on each one of its components
passing the chain. This will allow a very simple and straight forward
composition patters.

> But I also think that the refactoring Dave is working on will make the
> code simpler to understand/maintain and give more flexibilty. Let's
see
> what he comes up with and take it from there.

Simplification is good, and I am all for it. But the current solutions
seem to be requiring exposing more and more things tat users can break
instead of less. That looks like more complexity to me. May be I am
mistaken.

To be truthful, I have not even look at the 0.9 code. I work in 0.8 and
the implementation there seem to be quite simple and easy to understand.
Filters do not have init/destroy calls which from the conversation here
seem to be causing a lot of trouble. To me filters should be as
stateless as possible (they can keep any state they want in the
session).

And finally (this is getting way too long), I do not think one should be
able to cache the NextFilter object, just like that. It sounds wrong to
me.
Instead, I would suggest providing two methods:

 1) String NextFilter.getCurrentFilterName() : allows a filter to get
its name on the chain (I would enforce names to be unique).

 2) NextFilter IoFilterChain.getNextFilterFor(String name) : returns the
NextFilter instance that can be use to send something across. If the
named filter is no longer in the chain, you get null or some exception.

With something like this I think one really can simplify things.

Comments?

Jose Alberto

[Irving, Dave]

 
> Now, in this model it is very simple to define composite builders
since they just need to call the build method on
> each one of its components passing the chain. This will allow a very
simple and straight forward composition patters.

This doesn't change.

>> But I also think that the refactoring Dave is working on will make
the
>> code simpler to understand/maintain and give more flexibilty. Let's
see
>> what he comes up with and take it from there.

> Simplification is good, and I am all for it. But the current solutions
seem to be requiring exposing more
> and more things tat users can break instead of less. That looks like
more complexity to me. May be I am mistaken.

I think maybe I've made the change sound like more than it is.

All my first patch will do is make it easy for the inner workings of
mina to chain sub-chains together.
Basically, Im implementing your "EncapsulatedChainFilter" (in a slightly
different way to how you described).
As part of this, the AbstractIoHandler subclasses which provide
transport specific behaviour will be refactored in to normal filters
(this is an implementation detail of the change).

From the API perspective, nothing more will be exposed to the user (at
all) except for the following:

        - Ability to populate an acceptor specific chain with a builder
        - Alibity to populate a port specific chain with a builder
        - Ability to populate a session specific chain with a builder

The filter chain used for a given session will be the sequence of
acceptor chain, port chain, session chain.

Nothing else will change from the users perspective. If my
implementation makes it any easier for the user to break things, then
I've screwed up and any patch should be thrown in the bin :o)

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.

[Jose Alberto Fernandez-2]

> From: Irving, Dave [mailto:dave.irving@...]
>
>
> As per Niklas' email, we'll need to support a combined sessionManager
> chain, port chain and connection chain.
> Is there a clean way to do this that I've missed? Im certainly not
> interested in doing work for works sake :o)
>

My understanding of Niklas e-mail was that his main reason WAS spring.

>
> I think the refactoring we are talking about is not related to spring
> configuration per-se. In all cases, the three layers of chains will be
> available to be populated by a builder or whatever. The problem we are
> solving, as far as I can tell, is how to have re-usable chains of
> filters (sessionManager, port, session) cleanly and efficiently (i.e,
> not having to clone).
>

As long as you have addBefore/addAfter (which exist on 0.8, not sure
about 0.9) you will have to clone, as the filter chain is mutable. The
best you can do is to implement lazy copy. I do not see a real way out
of it.

>
> Niklas wants to specify re-usable port chains, and presumably its
> helpful to be able to specify re-usable session manager level chains
> (acceptor / connector). The problem to solve is how to cleanly hook
> these chains together.
> It seems that the proposed refactoring is quite a simple and
transparent
> way of doing this - but if I've missed an existing easy and clean way
to
> do this - please let me know - as I don't want to head down the wrong
> path!

So what happens when I call IoFilterChain.addFirst() on
sessionCreated(). As I said the best you can do is lazy copy.

Jose Alberto

[Irving, Dave]

> My understanding of Niklas e-mail was that his main reason WAS spring.

At the moment though, a handler which wants a certain filter per port
must have this logic (directly, or injected) in the handler.
It seems like a nice feature to be able to specify filters on a per
acceptor and port level.


> As long as you have addBefore/addAfter (which exist on 0.8, not sure
about 0.9) you will have to clone,
> as the filter chain is mutable. The best you can do is to implement
lazy copy. I do not see a real way out of it.

A mutable chain is fine with the proposed approach. The implementation
details have been discussed in earlier emails, but basically an owning
"CommandChains" (or something) class fixes the head and tail of
sub-chains (which users cant do) to manage sub-chain routing.
What this means is that whatever a user can currently do to a filter
chain, they will still be able to do after the chain.


> So what happens when I call IoFilterChain.addFirst() on
sessionCreated(). As I said the best you can do is lazy copy.

I don't think so. The filter chain a ** user ** is exposed to is just
the per session chain. The user can still make any changes to this as
they desire. They can clear it if they want!
The crucial bit is that the implementation (which the user doesn't see)
has fixed head and tail filters to manage the sub-chain routing. Users
can play with the filters all they want.

Hope this is clearer

> Jose Alberto


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.

[Niklas Therning]

Jose Alberto Fernandez wrote:

>>From: Irving, Dave [mailto:dave.irving@...]
>>
>>
>>As per Niklas' email, we'll need to support a combined sessionManager
>>chain, port chain and connection chain.
>>Is there a clean way to do this that I've missed? Im certainly not
>>interested in doing work for works sake :o)
>>
>>    
>>
>
>My understanding of Niklas e-mail was that his main reason WAS spring.
>  
>

The reason why I started to think about it was that I wanted to be able
to configure port-specific chains and still separate configuration from
use. This is what dependency injection (not only Spring) is all about. I
could as you pointed out have AbstractIoAcceptorFactoryBean make this
happen. But it would be more or less a hack, something I could live with
as a temporary solution but not in the long run.

>  
>
>>I think the refactoring we are talking about is not related to spring
>>configuration per-se. In all cases, the three layers of chains will be
>>available to be populated by a builder or whatever. The problem we are
>>solving, as far as I can tell, is how to have re-usable chains of
>>filters (sessionManager, port, session) cleanly and efficiently (i.e,
>>not having to clone).
>>
>>    
>>
>
>As long as you have addBefore/addAfter (which exist on 0.8, not sure
>about 0.9) you will have to clone, as the filter chain is mutable. The
>best you can do is to implement lazy copy. I do not see a real way out
>of it.
>
>  
>

Let's see what Dave comes up with, ok?

>>Niklas wants to specify re-usable port chains, and presumably its
>>helpful to be able to specify re-usable session manager level chains
>>(acceptor / connector). The problem to solve is how to cleanly hook
>>these chains together.
>>It seems that the proposed refactoring is quite a simple and
>>    
>>
>transparent
>  
>
>>way of doing this - but if I've missed an existing easy and clean way
>>    
>>
>to
>  
>
>>do this - please let me know - as I don't want to head down the wrong
>>path!
>>    
>>
>
>So what happens when I call IoFilterChain.addFirst() on
>sessionCreated(). As I said the best you can do is lazy copy.
>  
>

The chain you will have the opportunity to modify in sessionCreated will
still be the session private chain. Just like it always has been. Chains
won't be copied and you won't be able to change the port-specific or
sessionmanager-specific chain by calling
session.getFilterChain().addFirst() or whatever.

Bottom line: From a user perspective nothing will change. There will be
the extra opportunity to add a port-specific filter chain when you bind
an IoHandler to a port. Nothing more nothing less.

/Niklas

[Jose Alberto Fernandez-2]

So, there is no way for me to impose a Blacklist filter specific to a
handler before I do SSL and all other stuff someone else has configured
already at port level?

That does not sound right.

Jose Alberto

P.S. Do not take me wrong, I want the least amount of copying as
possible. As a matter of fact, once we have port level filters I would
move all session level settings to port level settings. Nothing else
makes sense to me.
Session level filters should only be used in very specific cases related
to the actual session you are working with. Hence, lazy copying will be
reduced to a minimum.

Jose Alberto

> -----Original Message-----
> From: Irving, Dave [mailto:dave.irving@...]
> Sent: 15 November 2005 15:12
> To: Apache Directory Developers List
> Subject: RE: [mina] Refactoring MINA IoFilterChain (Was:
> IoFilters: DIRMINA-121 / 122)
>
>
>
> > My understanding of Niklas e-mail was that his main reason
> WAS spring.
>
> At the moment though, a handler which wants a certain filter
> per port must have this logic (directly, or injected) in the handler.
> It seems like a nice feature to be able to specify filters on
> a per acceptor and port level.
>
>
> > As long as you have addBefore/addAfter (which exist on 0.8, not sure
> about 0.9) you will have to clone,
> > as the filter chain is mutable. The best you can do is to implement
> lazy copy. I do not see a real way out of it.
>
> A mutable chain is fine with the proposed approach. The
> implementation details have been discussed in earlier emails,
> but basically an owning "CommandChains" (or something) class
> fixes the head and tail of sub-chains (which users cant do)
> to manage sub-chain routing.
> What this means is that whatever a user can currently do to a
> filter chain, they will still be able to do after the chain.
>
>
> > So what happens when I call IoFilterChain.addFirst() on
> sessionCreated(). As I said the best you can do is lazy copy.
>
> I don't think so. The filter chain a ** user ** is exposed to
> is just the per session chain. The user can still make any
> changes to this as they desire. They can clear it if they want!
> The crucial bit is that the implementation (which the user
> doesn't see) has fixed head and tail filters to manage the
> sub-chain routing. Users can play with the filters all they want.
>
> Hope this is clearer
>
> > Jose Alberto
>
>
> 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.
>

[Irving, Dave]

> So, there is no way for me to impose a Blacklist filter specific to a
handler before I do SSL
> and all other stuff someone else has configured already at port level?

Every filter has the ability to know what handler a filter invocation
applies to if it really needs to (Each filter method is given a
IoSession. Then there is IoSession#getHandler).

> Session level filters should only be used in very specific cases
related to the actual session you are working with.
> Hence, lazy copying will be reduced to a minimum.

So presumably your blacklist filter would be at the port (or even
session manager) level - in which case you would configure it to come
before SSL.

Could you explain the problem further as Im not understanding how the
proposed chains wouldn't work for your example.

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.

[Jose Alberto Fernandez-2]

> From: Irving, Dave [mailto:dave.irving@...]
>
> > So, there is no way for me to impose a Blacklist filter
> specific to a
> handler before I do SSL
> > and all other stuff someone else has configured already at
> port level?
>
> Every filter has the ability to know what handler a filter
> invocation applies to if it really needs to (Each filter
> method is given a IoSession. Then there is IoSession#getHandler).
>
> > Session level filters should only be used in very specific cases
> related to the actual session you are working with.
> > Hence, lazy copying will be reduced to a minimum.
>
> So presumably your blacklist filter would be at the port (or
> even session manager) level - in which case you would
> configure it to come before SSL.
>
> Could you explain the problem further as Im not understanding
> how the proposed chains wouldn't work for your example.
>

Well the point, in this hypotetical case, is that I do not want to use
this
Blacklist filter on ALL my ports (IoAcceptor level). Lets assume this
filter is really part of the protocol I am implementing, independently
of whether I decide to use SSL or not. It would be nice if at each level
I can have access to the entire chain (from the socket to the handler)
and for me to manipulate as I please. You could be able to implement
handlers that can reconfigure its entire chain as they go, if so they
please.

Now, for this to be safe, you would need to do lazy copy, so that when
such an action occurs you stop sharing.

Jose Alberto

[Irving, Dave]

> Well the point, in this hypotetical case, is that I do not want to use

> this Blacklist filter on ALL my ports (IoAcceptor level). Lets assume
this
> filter is really part of the protocol I am implementing, independently
of whether
> I decide to use SSL or not.

Ok, I see. However, even in this hypothetical case: Wouldn't you just
configure SSL at the port level too (not acceptor level).
Then there wouldn't be a problem.

Sorry for probing - Im just trying to establish whether there is any
real need for exposing the whole chain on a per connection basis. If
there is, it makes this change a fair bit more complicated :o)

> It would be nice if at each level I can have access to
> the entire chain (from the socket to the handler) and for me to
manipulate as I
> please. You could be able to implement handlers that can reconfigure
its entire chain
> as they go, if so they please.

> Now, for this to be safe, you would need to do lazy copy, so that when
such an action
> occurs you stop sharing.

I hadn't planned to expose the whole chain as part of 121 / 122. I think
its probably quite a bit more complicated to implement than what we're
planning to do at the moment.
If we do really need it - it would be good to know at the earliest
opportunity - as Im starting to implement a proposed solution for
121/122 now

> Jose Alberto

Thanks,

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.

[Jose Alberto Fernandez-2]

> From: Irving, Dave [mailto:dave.irving@...]
>
> Ok, I see. However, even in this hypothetical case: Wouldn't
> you just configure SSL at the port level too (not acceptor level).
> Then there wouldn't be a problem.
>
> Sorry for probing - Im just trying to establish whether there
> is any real need for exposing the whole chain on a per
> connection basis. If there is, it makes this change a fair
> bit more complicated :o)
>

Yes, for this specific example, you may be right. But lets assume some
other.
Lets assume I have a port level filter configuration consisting of:
threadFilter,
kerberosFilter, codecFilter, and someFilterManager.

Now, as part as the protocol, the client may request TLS privacy once
authenticated.
So, on a particular session, the client requests privacy, which means
adding the SSLFilter
after threadFilter and activate it. Now I want this change only for this
session, not for all the sessions on this port. I cannot do SSL at the
end of the chain because I need to decode first.

This means I need to reconfigure the chain, just for this session. Now
the current solution requires my to setup the entire chain on a session
by session basis (which is really waistful as we all agree). If instead
you share the chain, and only do the cloning on demand (when SSL is
reqested by a session) then you can save on average.

And since you have only one chain (either shared or private) at any
given point in time, the implementation has to be simpler. I do not see
how it may become more complicated.

Jose Alberto

[Alex Karasulu-4]

Looks like the traffic is picking up on MINA and things are heating up
as we approach 1.0.  Initially my thought was to get a separate list for
MINA however I'm thinking it might be best to just see if we can promote
MINA to a TLP.  It has out grown its place in directory and many
projects will depend on it.  It makes sense to me to see it acquire a
life of its own.

There's a good sized community brewing around MINA.  I'd like to see
more people come forth as committers then see if we can get a proposal
before the ASF board on budding off the MINA project.  IMHO this is
better than creating a separate mailing list.

Right now it would be good to see who favorrs this?  Any comments or for
or against this idea?

How about a little poll:

[ ] +1 MINA should become its own TLP at Apache
[ ] +0/0/-0 Maybe later, or let's get a separate mailing list for now etc.
[ ] -1 MINA should remain at Directory as is

Alex

[Irving, Dave]

Jose Alberto wrote:

> Now, as part as the protocol, the client may request
> TLS privacy once authenticated.
> So, on a particular session, the client requests privacy,
> which means adding the SSLFilter after threadFilter and activate it.
> Now I want this change only for this session, not for all the sessions

> on this port. I cannot do SSL at the end of the chain because I need
> to decode first.

Thanks - that makes perfect sense and I see where you are coming from
now.

> And since you have only one chain (either shared or private) at any
given point in
> time, the implementation has to be simpler. I do not see how it may
become more complicated.

If we're supporting sharing, then we need the existing proposed changes
to support that. The lazy copying comes on top of this - so Im not sure
the overall change would be simpler.
To support this, we'd need to work out how to do the lazy copying you
are talking about.
I don't think its so simple as IoFilters are initialised with a
NextFilter and are allowed to use that filter at any time to make
requests. So we'd either have to change the way they do this as you
discussed earlier (effects all filter implementations) or we'd have to
make them cloneable (or whatever. Again - effects all filter
implementations).
Either change is likely to have big impacts - and with my level of Mina
experience I think I'd have to take a back seat and leave it to the
experts (which is the best thing all round if there is a better way to
do this that Im not yet up to implementing).

The only easy way I can think of doing what you want (without requiring
changes to the Filter API) is as follows:

We now have the ability to make "chains of chains" very simply (routing
based on session).
There is nothing to stop us allowing a session to make a chain
"contribution" at any point along the "chain of chains".
E.g, in your IoHandler you realise that your client has requested TLS
which must come before anything else.
You'd do this:

IoFilterChain chain = IoSession.getSessionChainBefore("sessionManager");
// configure the chain how you like
chain.addLast(myTlsFilter);

The chain would be created on demand and you could modify it however you
wanted. For all subsequent traffic, your tls filter would be the first
filter used.

Most users would probably not need this however, and would just get the
"regular" session chain:
IoFilterChain sessionChain = IoSession.getFilterChain();


I understand that this may not be good enough: For example, you may now
say that if they want TLS, you should remove some other filter that was
configured at the port level. This solution wouldn't support that as it
stands. (I suppose it would be possible to opt out of filters with more
work though).


So, in summarry (sorry, it was long again), I don't see how the Lazy
Copying can work without changes to the API and semantics of IoFilter -
which Im not experienced enough to contribute to.
Please let me know if my proposed additional change is likely to be of
use to you.

> Jose Alberto

Many thanks,

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.

[Simon.Temple]

+0

15 November 2005 17:27
To: Apache Directory Developers List <dev@...>
cc:
From: Alex Karasulu <aok123@...>
Subject: Yall need your own list (was: Re: [mina] Refactoring MINA
IoFilterChain (Was: IoFilters: DIRMINA-121 / 122))



Looks like the traffic is picking up on MINA and things are heating up
as we approach 1.0.  Initially my thought was to get a separate list for
MINA however I'm thinking it might be best to just see if we can promote
MINA to a TLP.  It has out grown its place in directory and many
projects will depend on it.  It makes sense to me to see it acquire a
life of its own.

There's a good sized community brewing around MINA.  I'd like to see
more people come forth as committers then see if we can get a proposal
before the ASF board on budding off the MINA project.  IMHO this is
better than creating a separate mailing list.

Right now it would be good to see who favorrs this?  Any comments or for
or against this idea?

How about a little poll:

[ ] +1 MINA should become its own TLP at Apache
[ ] +0/0/-0 Maybe later, or let's get a separate mailing list for now etc.
[ ] -1 MINA should remain at Directory as is

Alex