On Mon, Feb 20, 2012 at 12:47 PM, Herman Bruyninckx 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. best regards, -- Ingo Lütkebohle Bielefeld University http://www.techfak.uni-bielefeld.de/~iluetkeb/ PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B