mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel LŽcharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Tue, 15 Dec 2009 12:30:46 GMT
Hi,

there is another approach if we switch to a SM : actions don't need to 
know about the next action, as it's computed by the SM. We can end with 
methods like :

messageReceived() {
  blah
}

and when the method returns, the SM decide which filter to call next. 
This end up with something like :

while ( not Done ) {
  nextFilter = computeNext(session);
  nextFilter.messageReceived(session);
}

The only constraints being that we don't have code like :

messageReceived(session) {
  blah();
  call next filter; // Not necessary anymore...
  post_blah(); /// Wrong !!!
}

Now, why did we used Filters at the origin ? It's important to know that 
when Alex thought about what should be MINA 6 years ago, and before 
Trustin joined the project, the idea was to implement a SEDA based 
framework.

What does it imply in real world ? Many things. First, transition 
between one filter and another should allow the use of a queue, so 
interactions are asynchronous. Another aspect is that we may have more 
than one thread running on one session (some decoding can occur while a 
new message is being received). Another consequence is that we may have 
unordered messages : if two threads are being processed for the same 
session, one can be faster to decode than the second one, and the second 
one can perfectly well hit the Handler before the first one. We have 
some mchanism to protect the user from such a problem.

Ig we have to keep this SEDA approach, then we must be careful and be 
sure that we can process each filter separately. looking at the loop I 
exposed above, we will have a problem because the loop is executed 
sequencially by one single thread, so we can't anymore implement any 
SEDA mechanism.

If the filter is responsible for the call of the next filter, then it's 
a totally different story.

We have to think about this before drafting some implementation, and 
decide if we want to stick to SEDA.

Now, some comment in line about Alan's last mail

Alan D. Cabrera a écrit :
>
> <Snip/>
>>>> 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.
You are probably right. If you look at the existing filters, there is no 
reason we should not be able to avoid such code.

>
>> 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.  
I can't agree more :)

> One the goals should be to get rid of as many useless "helpful" 
> classes and methods as we can.
+1

>   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.
I would like to keep the SM approach, but as explained above (SEDA 
thing), I think we should be driven by the code.

> <snip/>
>
> I totally agree with this approach to deciding on the API and am happy 
> to help out w/ some protocols, e.g. HTTP and SSL.
>
> I am curious, what project feels that it needs to do an "implicit" 
> state machine?  I would love to take a peek at the code.
What do you mean by "implicit" state machine ?


Mime
View raw message