I think this is a good feature !
In the first design I commited there was an Instance object ! You told me to remove it as an instance is an execution...
By now I am managing a rootExecution which is not a good design... So I agree with you on creating an Instance class !
the difference with this proposal and the previous approach is that now, a process instances *is* an execution.
i'm not yet all in favour. i mainly would like to have a better picture of how this will impact the user API. I'm still worried that the user will have to start casting from execution to process instance or that some methods use process instance and others will use execution in a non-uniform way.
to show that point, i could ask the question: "What if we add a boolean method/property in the execution class isProcessInstance() ? Wouldn't that lead to a simpler user API ?"
we just have to rename rootExecution to Instance...
maybe later, an Instance could have more properties than an execution... For example, we can have a way to set instance specific configuration...
We can imagine many other cases...
If we don't create an Instance class, it means we will have to add a lot of features in Execution having no sense for the major part of all executions...
yes. from a design point, that makes sense. but the question i still have is from a user API standpoint. wouldn't it complicate things unnecessary ? as users will have to know when to use instances and when they should use executions. whereas if it's all execution, the developer using our API's cannot make mistakes and just puts in the execution.
There are already a lot of concepts to know before starting to play with the PVM API so I don't think is gonna be hard for a developper to get the difference between instance/execution :-)
Even more, I think it could be useful at different moments of the dev process to just type "instance" when refering to the rootExecution (i mean is more natural for a workflow/BPM developer)