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.