>>
>>>> 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 :-)
--
thanks
ashish
