mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan D. Cabrera <l...@toolazydogs.com>
Subject Re: [MINA 3.0] filter chains
Date Fri, 26 Aug 2011 17:22:54 GMT

On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:

> On 8/26/11 6:16 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
>>> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>>> <theory>
>>>> In a FSM, you transit from Si to Sj, following a transition Ta, which depends
on a context. You may also transit to a state Sk, following a different transition Tb, if
the context is different.
>>>> Selection the transition to follow is all about knowing what's the context
is, and in my sample, this was what I call the 'state', which was most certainly an error,
as it's clearly a transition. I should have wrote :
>>>> F --(transition1)-->    G
>>>> or
>>>> F --(transition2)-->    H
>>>> where F, G, H are filters (ore "states")
>>>> are we on the same page ?
>>>> </theory>
>>>> Not at all.  :)
>>>> Are F, G, H filters inside the FSM or are they external to the FSM?
>>> They are filters in the FSM.
>> Ok, now I know where you're coming from.  For me I have a map of chains
>> Map<State, Chain>  states = …
>> State current;
> What is Chain in this context ?

Chain is a simple filter or graph of filters that can declare what the next state of the FSM
should be.

> I don't think it's enough to build the demux. We probably would need something like :
> Map<Status, Filter> filterMap = ...
> Map<Filter, Map<Status, Filter>> fsmMap = ...
> ( I keep Filter, but a Filter for us is a State in a FSM)
> otherwise, the controller can't select the next Filter without having a clue about the

Ahh, cool, more clarity.  I never intended FSMs to replace a demux.  

>> void send(T message)
>> {
>>     Chain chain = states.get(current);
>>    current = chain.send(message);
>> }
> 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.  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.

> 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.  Our tendency is to
dive into the implementation details and then shoehorn protocols into the resultant API. 
This is why Mina 2 is so bloated and daunting.  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.

To that end I invite everyone to flesh out, as I am doing in my sandbox branch, the following

Link state protocol - implementation of [1]
Group protocol - [2]
Paxos - ideally would use the above protocols

[1] http://caltechparadise.library.caltech.edu/32/
[2] http://authors.library.caltech.edu/5410/


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message