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.
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
Our tendency is to dive into the implementation details and then shoehorn
protocols into the resultant API.
Not exactly my state of mind... I'm more trying to find the best
possible solution, dealing with many constraints :
- ease of use
- coverage of the different use cases
- memory consumption
- ease of debuging
- speed
This is why Mina 2 is so bloated and daunting.
MINA 2 is bloated for different reasons, and I think I have already
discussed some of them.
One of the most problematic reason is that MINA 2 (and 1) was a one man
show. This is why I'm really pleased to have those discussion here, even
if it seems to be a bike-shedding discussion. It is not.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
