On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
Map<Status, Filter> map = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
This strikes me as pretty complex, jmho. Also, I don't like the idea of
forcing the filter to call the controller.callNextFilter() to make things work.
the alternative would be something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
fsmMap.get( this ).get( status ).messageReceived( context );
... // do something after the call
}
No controller, but a long list of chained call.
But we're still forcing the filter to participate in things that really should
be the domain of the controller not the filter.
If we delegate the transition to the controller, then we can't have post
actions... Obviously, not having post actions makes it easier. (Post
action are really important if we want to do something when we come back
from the application.)
One clear exemple would be a decoder processing a PDU with more than one
message : you can't anymore loop on the PDU if you delegate the next
call to the controller.
With that said I think that an FSM where we have, here letters are filters:
[outside filter] -> {A -> [state change decides to send to] -> B -> [state
change decides to send to] -> C} -> [outside filter]
is very confusing. What protocol would require that? Just an honest question;
one does not come to my mind atm.
all of them :) This is what we currently do in MINA.
Also the fsmMap must be known by the current filter.
Look at my implementation of org.apache.mina.link.DownState as an example.
This framework does not require a call to a controller for the whole thing to
work. This filter merely focuses on its task at hand and implementation does
not leak as much into its message received method.
Ok, I'll give it a look.
The controller will decide which filter must be called depending on the context
status.
(Note that the controller should also decide which message to call, for
instance, it can decide that it has to call a messageReceived() because it's
caller was processing a messageReceived())
I feel that, for the most part, we all have been doing a lot of discussions
without any mock implementations of real protocols to help us gauge our API
decisions.
I'm "lucky" enough to have played with MINA for more than 5 years, facing many
differents kind of protocol based on it, plus having answered many of MINA user's
questions regarding how to implement many different kind of protocol.
Trust me on that, when I'm thinking about the new API, I always have in mind the
different "real world" protocols we have to deal with. That includes :
- obviously LDAP protocol, which is a binary, two layer codec, demuxed protocol
- NTP based on UDP
- Kerberos based on UDP *and* TCP
- HTTP, ie newline terminated decoder, a cumulative decoder
- a few proprietary protocole implemented using MINA, with fixed size data, or
LV type PDUs
I think you missed my point. I am not questioning anyone's expertise in the
industry. I am calling out the current modus operandi of the current API
design process and it's need for real world mockups.
Ok, understood. You are reverting the process : we define the protocols,
then we try to implement them with different way to manage filters.
I'd like to see lots of little sandbox branches where people show what
protocol implementations would end up looking like for the feature they are
proposing. It's a fantastic way to gauge API design differences.
I like Julien's approach : designing a working solution, not covering all our
bases right now, and implement a few existing protocols. Then moving forward.
I'm sorry but that seems totally backwards to me. The API design should be the
framework from which the working solution evolves. Starting with the
implementations could automatically close the doors on useful API features.
Unless we ditch those implementations. But I understand your point.
However, even if we define some protocols, we will need some
implementation to test them.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
