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 ?
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
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 );
}
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())
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
