On Mon, 20 Feb 2012, Ingo Lütkebohle wrote:

> On Mon, Feb 20, 2012 at 12:47 PM, Herman Bruyninckx
> <Herman.Bruyninckx@mech.kuleuven.be> wrote:
>>> The TSP only talks about the state of /tasks/, these being actions
>>> that a component performs. For components which have an internal
>>> life-cycle FSM, they usually only perform tasks while in their
>>> equivalent of a "running" state, but they may not constantly be
>>> performing tasks. For example, a trajectory planner may be ready for
>>> planning (i.e. the component is running, configured, and so on), but
>>> not actually do anything, until it gets a target input.
>>>
>>> We think it is useful to track not only the state of the components,
>>> but also the state of the tasks.
>>
>>
>> FSM deal with (discrete) _behaviour_ of components, your 'task tracker' is
>> all about _data structures_ of where the execution of a task is wrt to
>> where it is expected to be. These are two very different concerns, so you'd
>> better keep them separate.
>
> I'm not sure we're talking about the same thing here. The TSP models
> state in a discrete fashion, with states such as "initiated"
> (submitted by the client for execution), "accepted" (marked by the
> server as executable), "running" (in execution), "completed/failed",
> etc. The only _data structure_ it has contains metadata such as the id
> of a task and its current state.
>
> It is explicitly /not/ about the internal progress measure, which is
> usually specific to the component. In fact, the separation between
> these specific information items and the abstract state is one of the
> central ideas. Thus, unless I understood you wrong, it explicitly
> realizes the separation you're asking for.

Okay, I understand the gist of your remarks, but I am not sure whether I
understand them. (Which is as much my "fault" as yours :-)). I will need
some more exposure to examples your are working with. (But don't feel
pressed to provide them now; that's probably something we should discuss in
a face to face meeting somewhere, some time :-))

> best regards,
>
> -- 
> Ingo Lütkebohle

Herman