execution interfaces

[tom.baeyens]

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 ?

[csouillard]

Good idea to split.
By now this is very hard to use pvm api in a safe way...
We already had problems using some methods in a wrong way...
Sometimes we can write some code working but with side effects
Maybe execute method could use the interface for actions ?

Charles

[mvaldes]

I agree as well...

Cast would not be needed all the time, i.e in NodeBeaviour and Action impls. ExecutionController and ExecutionState could replace Execution parameter respectively.

regards,
Miguel Valdes

[tom.baeyens]

first iteration is done and committed. please review to see if it makes sense

[tom.baeyens]

renamed ExecutionState to ExecutionAccessor to prevent a name collision with Execution.state property.

The execution state indicates wether an execution is active, ended, cancelled, suspended,... and it also supports user defined states (it's a string property)