mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashish <paliwalash...@gmail.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Tue, 15 Dec 2009 04:15:05 GMT
>>>> Not necessarily, for three reasons :
>>>> 1) if the chain is fixed at startup, you can't anymore inject a
>>>> LoggingFilter when the server is running. You can only activate or
>>>> desactivate it. Not that it's realy a big issue, but it may help in some
>>>> case (that also mean we have a way to control the execution. JMX ?)
>>> One normally doesn't turn on and off things like that on a per message
>>> basis.  What I mean by that is that each filter decides to do what it needs
>>> to do.  That includes logging.  Constantly injecting logging filters on an
>>> ad hoc basis is a very, very, poor practice.
>> A very, very rare practice, hopefully :) Here, i'm not sure it worth it
>> anyway. I really think it's better to enable the filter instead of injecting
>> it dynamically. In any case, I'm ready to lose this "feature"...
> Agreed, not a very compelling use case.

+1. Enable/Disable a Filter is way better than injecting filter's on
ad-hoc basis.

>>>> 2) Most important, if we don't have a clue about which is the next
>>>> filter in the chain, that leads to problem when debugging, as you can't know
>>>> which filter will be called. Ennoying
>>> Sure you do.  The chains are fixed.  If you know what filter you are and
>>> what state you're in you know what filter gets called next from the
>>> perspective of the framework.  From the perspective of the filter you
>>> shouldn't care what's next, if you do then you've introduce a brittle
>>> dependency.  For me that;s usually a red flag that I haven't thought through
>>> a design and it needs to be revisited.
>> Let me clarify my mind : when stepping through filters while debugging, I
>> want to be able to jump directly to the next filter. In order to do that,
>> code like :
>> Filter nextFilter = computeNext( session );
>> nextFilter.call( session );
>> is mandatory. I don't want to experiment the same pain as with Spring,
>> when I have to open two editors, one for my java code, and another one to
>> see what is supposed to be my SM. I went through this pain so many times in
>> the past with MINA that I don't want to suffer such a pain again...
> Yeah, nothing is more frustrating than stepping though layers of container
> code.  That's why I configure my debugger to skip those chunks of code so it
> lands directly in my POJOs.  Anyway, since the chains are fixed the filter
> dispatching code is quite simple:
> Filter current = filterChain[state, i++];
> current.call(session);
>>>> 3) Last, not least, we want to be able to call the next filter in the
>>>> middle of a processing :
>>>> messageReceived() {
>>>> do blah();
>>>> if ( condition ) {
>>>> do anotherBlah();
>>>> call Next filter();
>>>> } else {
>>>> do yetAnotherBlah();
>>>> call nextFilter();
>>>> }
>>>> do endingBlah();
>>>> }
>>> That just tells me that you have mixed up two states into one and that
>>> you need to expend a little more effort into your state machine design.
>> From the user POV, it's way more easy to write code this way than to
>> create two (or more) states. The idea is to combine the state machine vision
>> with the chain vision. You can express everything with a SM, and implement
>> it in a simpler way...
> Easy, yes, initially and if you're the only developer but not so much more
> easier that your point is self evident.  But remember, we all agreed that
> the developer is doing this to create a state machine.  The above code is
> brittle and lacks the explicit states.  I would argue that it's an
> anti-pattern.
>>>> Not sure this is possible in another way than with those computed
>>>> nextFilter() inside the filters.
>>> I agree but it's my contention that it's a bad practice that supports an
>>> ill thought out protocol.
>> The biggest advantage is that it eases the implementor work most of the
>> cases.
> IMO, it's sloppy and error prone and obfuscates code.  If no one else agrees
> then I'm happy to drop my point.

Have a request here. Can you help us here with a small POC.
We can compare and have User communities opinion on this.
But let's not just drop it :-)

>> Now, it does not preclude that we should not allow someone to implement
>> his protocol using a complete state machine. May be we should provide both
>> mechanisms :
>> - one which is driven by the code (ie, the code 'pull' the next step),
>> - one which is driven by the state machine (your way).
> I would argue against this.  Mina is afflicted w/ bloat.  One the goals
> should be to get rid of as many useless "helpful" classes and methods as we
> can.  Either we all agree that adding filters in an ad hoc manner is a best
> practice for network protocol state machines and we loose the state machine
> or we agree that it's an anti-pattern that should be avoided.  If the
> community thinks that ad hoc filters are a best practice I'm happy to drop
> my point.

-1 for ad-hoc filter addition feature.
We have FtpServer, SSHD, Asyncweb and I believe other's (like Red5)
are hooked to dev list.

We are interested in your voices :-)


View raw message