4 Replies Latest reply on Aug 6, 2007 5:04 AM by Tom Baeyens

    execution interfaces

    Tom Baeyens Master

      i thought about splitting execution interfaces.

      the motivation is to give users of the API better guidance on what execution methods they can use in following different situations.

      1) when implementing an Action
      2) when dealing with non-running executions (in a wait state).
      3) when implementing Node Behaviour

      So I am experimenting with the following interface hierarchy:

      ExecutionState : An interface that provides read only access to the current state of the execution (e.g. node, event, executions,...). Target of this interface is Actions. The action's execute method would get an ExecutionState. ExecutionState is the most restricted access to the execution. But even in this interface, read/write is given to the variables and properties like priority.

      Execution : An interface extends ExecutionState and is targetted for external clients that manipulate the execution when it is in a wait state. It adds signal and end methods.

      ExecutionController : This interface extends Execution and adds methods needed for the NodeBehaviour implementations like e.g. performAtomicOperation, createExecution,...

      Then class ExecutionImpl would be the only implementation class that actually implements all of the above. Since this is the only implementation class, clients that want to do something tricky can always cast to a more powerfull interface or event the ExecutionImpl implementation class.

      I think this would give more guidance to API users. As it stands now, the execution class offers all the methods to all 3 use cases described above. Many methods are not allowed to be called in one or more use cases.

      The downside is that implementors will have to cast once and a while if they want to do something tricky.

      Thoughts ?