[Zope-CMF] [DCWorkflow] active workflows

[Florent Guillaume]

Dieter Maurer  <dieter at handshake.de> wrote:
> 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 ;-)

This changed gets a +1 from me too, it's a good addition to DCWorkflow.

> 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.

Yes that works, if you have a good external scheduler, and all your
objects (or part of the workflow) notify the scheduler of anything that
may affect the object's scheduling.

> 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.

Ok that's an artefact of your model, where the you don't strictly know
the time where your object will have to follow its next transition, but
has to be probed because it may not be ready.

> 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)".

That could work, but it looks like a simple variation on listActions,
no?

Myself I was thinking of a slightly simpler
wf_tool.canDoActionFor(object, action) that would return a boolean.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com