We're currently extending workflow for a client (on HEAD). Some of the extensions are generally useful, and these go in workflow, while some are very client-specific, and do not (they go in contrib/packages/simulation, to be specific).
What I wanted to say here is that we've come up with a design for defining workflows in an extensible way.
An abstract workflow consists of some information about the workflow itself, plus a list of actions and roles.
A workflow based on a finite state machine (which is currently the only model supported) adds states, and extends actions with information about in which states they're enabled. So it extends workflows by adding states, and it extends actions by adding FSM-specific information.
On top of this, the simulation package extends workflows, roles, and actions with additional columns.
To implement this, we have built the workflow API in a way that allows API calls such as "get", "edit" (handles insert/update/delete), "generate_spec", "clone", and "new_from_spec" to extend each other, so each layer - workflow, FSM workflows, simulation workflows - handles its own attributes and calls the parent to handle the parent attributes.
It's very much like what acs_objects do at the PL/SQL layer, but here we have a Tcl API layer, that also manages to spit out a textual representation, which you can then distribute with your application or load onto another server.
And the scheme works whether the items involved are acs_objects or not.
I just wanted to point this out, so if other people need to do something similar, they know where to look for an example, and perhaps we'll have an emerging practice. Could be useful for user information, projects, or many other types of objects.
/Lars
