[Zope-CMF] [DCWorkflow] active workflows

[Dieter Maurer]

Julien Anguenot wrote at 2005-1-7 20:55 +0100:
> ...
>| Indeed, the scheduling service should be an independent service
>| which is just used by the workflow. It is useful for other features
>| as well.
>|
>
>When I ment scheduling hooks I ment as well the changes you proposed
>since

The only change I proposed to DCWorkflow was the addition of
"script_on_entry" and "script_on_exit" to states. I saw
a +1 for this from you ;-)
Everything else could be achieved with standard DCWorkflow
but, as Florent pointed out, would cause quite heavy effects
from transitions.

> as stated Florent, it's possible to achieve your goal with
>workflow variables and catalog.
>Though, you might be right for the scaling problem but then the issue is
>on the catalog and not on the workflow anymore...

That's not my view: the scaling problem does not come from
the catalog but from the pull versus push approach.

Florent suggests a "pull approach". Something continuesly
(with some resolution) queries the catalog whether there are
things to execute. Most of these queries will return nothing,
as it is quite rare that something needs execution -- a waste
of time.

I suggest a "push" approach. The objects with need for execution
scheduling explicitely register their needs
with a scheduling service. This specialized service can
perform the scheduling *MUCH* more efficient (see Python's "sched" module)
than something based on the general purpose catalog.


Moreover, the catalog based approach has the same transition
problem that was pointed out by Florent. The cause of the
problem stems from the fact that after the given time,
the transition may not yet be ready and a rescheduling is
necessary. I proposed a (normal DCWorkflow) transition
"probe" for this. A normal transition changes status.
When rescheduling is necessary, a catalog based approach
would need to change the "execute_after" variable (such that the
status is written) or would from then on check the transition
condition in each time unit.

I fear an additional extension to DCWorkflow will be necessary
to allow to check for the transitions effectively available
in a given object state.

>But I'd really would like to see your state extensions with the scripts
>that can be executed while entering and exiting the state within
>DCWorkflow. We've been talking about adding this feature to CPS workflow
>~ couple of time ago.


Modulo the "status writing in case of rescheduling necessity" issue
(brought up by Florent)
that's the only thing I need as DCWorkflow extension.

To address this issue, I will further need a new
"wf_tool.listCurrentlyAvailableTransitionsFor(object, wf_id=None)".

-- 
Dieter