Execution state persistence for workflow application

[Paolo Losi]

Serge Orlov wrote:
>>Questions are:
>>
>>- does there exist a python framework for workflow that use
>>   python script as a specification language and that
>>   support "long running" workflows? I don't want to reinvent the wheel...
> 
> Not that I'm aware of.
> 
> 
>>- does the implementation idea quickly depicted makes sense to you?
> 
> Partly. It's not complete and that makes it look more simple than
> data persistence when it's not. The problem is that one day you will
> have to upgrade your program and your last dumpexec won't be
> compatible with your next loadexec(). You will have to separate
> code from data to do it. So it means execution persistence is not
> enough for real life use. Why not just use data persistence alone?

In fact data persistence is not sufficient to stop and resume scripts
in case, for example, system reboot.
I do want my workflow scripts to resume exactly (and with the same
globals/locals setup) where they left...

The real alternative would be to define a new script language
with standard constructs (for, while,...) but again... i don't want
to reinvent the wheel.

I do not seen execution persistence as an alternative to data
persistence: I would need both.

>>- how do you suggest to implement execution persistence? Is there
>>   any "standard" solution?
> 
> Use data persistence and your own custom loader. Don't be afraid
> of the word loader. It's very simple. For a simple persistant "hello,
> world!" program it's about 5-10 lines. I think ZoDB is the most
> popular data persistence framework. It's very nice and simple.
> 
> -- Serge. 

	Thanks!
	Paolo