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 context
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 protocols:
Link state protocol - implementation of [1]
Group protocol - [2]
Paxos - ideally would use the above protocols
SSL
Checksum
MUX/DEMUX
[1] http://caltechparadise.library.caltech.edu/32/
[2] http://authors.library.caltech.edu/5410/
Regards,
Alan
