Scope
-----
I still think the scope of the project is the first thing that must be decided upon before discussing which solution is the best. There are lots of options here and covering them all is impossible.
The scope I am interested in is (see the worfklow page on the Wiki):
- a solution for developers;
- although initially we were planning on using workflow for document management (object lifecycle), we might need a solution which can be used to implement more general processes too;
- whether a general workflow instance can be attached to a single object is questionable. A generalized workflow will involve many documents/objects (some of which will only be used by that workflow instance). I think that in a generalized workflow framework the workflow instance itself must be an object with which the developer interacts directly instead of the workflow instance being hidden.
I really would like to see more use cases appearing from which we can pick a set to implement using different technologies. I will add more use cases in the near future.
Standards
---------
Thank you Andreas for putting up the list with standards. We can use these for input and reflection upon our decisions.
Conforming to standards is an honourable goal and it has its pros and cons. Pros:
- make use of available tools;
- people outside of Cocoon are probably more interested;
- no reinvention of the wheel. The standards are complex because they were defined by people with a lot of experience in the field. Chances are that if you start out small you end up with the same complexity after several years.
Cons:
- it's not easy to use for simple use cases. A period of learning is unavoidable;
- huge effort to build a compliant solution.
Interface
---------
The interface provided by Guido makes things more concrete, but, although I like state machines very much, I think too much terminology of state machines is in the interface.
Also the interface assumes there will only be changes from one state to another state, but in concurrent state machines and generalized workflow a single trigger can cause multiple state changes including forking and syncing.
I think the scope needs to be clearer before we can start thinking about the interface. Otherwise it might change too often as more requirements are added.
Implementation
--------------
In my opinion no particular technology, e.g. Flow, must be a requirement for a workflow implementation. I thought the workflow provider would be an Avalon service. This makes it accessible from everywhere and usable outside Cocoon.
Conclusion
----------
IMHO there should be more consensus about what is needed and what is feasible in a relatively short time, e.g. half a year to a year.
I think building a generalized workflow based on a standard is too ambitious. Leaving out some more complex constructs decreases usability. It might be an option to choose a (proper) subset of a standard with which a large percentage (definitely more than 80%. Having to resort to another solution in one of four situations is not acceptable) of use cases can be implemented.
-- Johan Stuyts, Software Department Hippo Webworks Grasweg 35 1031 HW Amsterdam The Netherlands Tel +31 (0)20 6345173 Fax +31 (0)20 6345179 johan(at)hippo(dot)nl / www.hippo.nl
