On Dec 15, 2009, at 4:30 AM, Emmanuel Lcharny wrote:
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
}
Yes, this is along the lines of what I was thinking.
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);
}
This is not much better than what we had before. The chains should be
fixed.
while (!session.closed())
{
List<IoFilter> filters = session.getChain(session.getState());
for (IoFilter filter : filters) filter.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 !!!
}
Yay!
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.
Agreed. This is something we should support. I think that the
original complexity came from mixing concerns.
What if we had channels that could contain things like queues, state
machines, etc.? Channels would be bidirectional, i.e. messages would
move up and down in a single channel. We would then compose channels
in fixed DAGs.
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 ?
In the "ad hoc" state transition approach the state transitions are
implicit in the code rather than explicit and fixed in a set of data
structures. To understand the implicit state machine one must
carefully read all the code to understand what's going on.
Regards,
Alan
