mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] filter chains
Date Fri, 26 Aug 2011 18:03:15 GMT
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


Mime
View raw message