On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>
>>> 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.
>> But we're still forcing the filter to participate in things that really
>> should be the domain of the controller not the filter.
>
> If we delegate the transition to the controller, then we can't have post
> actions... Obviously, not having post actions makes it easier. (Post action
> are really important if we want to do something when we come back from the
> application.)
I think we're getting to some interesting bits. Can you provide more exact
detail?
>
> One clear exemple would be a decoder processing a PDU with more than one
> message : you can't anymore loop on the PDU if you delegate the next call to
> the controller.
What is the format of this PDU and how is it presented to the FSM, i.e. in what
kind of pieces does it arrive?
>> With that said I think that an FSM where we have, here letters are filters:
>>
>> [outside filter] -> {A -> [state change decides to send to] -> B ->
>> [state change decides to send to] -> C} -> [outside filter]
>>
>> is very confusing. What protocol would require that? Just an honest
>> question; one does not come to my mind atm.
>
> all of them :) This is what we currently do in MINA.
I think that I am hearing a reply that explains that all the protocols are
implemented in this way. I'm not hearing an explanation as to why it *must* be
that way.
Regards,
Alan
