Batov, Vladimir wrote:
In my spare time I've been fooling around with an implementation of an infrastructure that would allow workflow to be configured at run-time.
A well-defined process flow is clearly easier to configure/implement at compile-time using the conventional means (coding). Say,
bool my_process_flow() { if (call_a() == success/true) { return call_b(); } else { return call_c(); } }
However, to be able to quickly adjust to changing customer requirements and/or procedures we might decide to provide a set of building blocks (like call_a, call_b, call_c) that could be assembled into a certain process flow at run-time. Maybe even give that ability to the customer themselves through, say, GUI interface.
...
Now after such a long and boring introduction to my actual question. :-) Is there any interest in having/developing such an infrastructure under the boost umbrella? Any input is welcomed even if you think it is a crappy idea.
I am not sure whether I understand what this is about ('workflow' and 'customer' being two words I have never had cause to associate with any programs I write ;), but is this applicable to the checkpointing problem? ie, I have a long-running job running in a batch queue, and it gets a signal to terminate (say, by the CPU or wall-clock time exceeding some limit, or perhaps an actual unix signal), so it needs to checkpoint and submit a continuation job to the queue. The serialization part is straightforward, but it needs to break out of the main loop at some point and then restart it later. I currently do this with a 'TaskQueue', which is simply a queue of polymorphic (and serializable!) objects with a 'Run' function. Task::Run() itself returns a TaskQueue which is appended to the front of the queue. If this relates in any way to what you are doing, then YES, I would like a much cleaner and boost-ified way of doing it. Is boost::function serializable? Cheers, Ian McCulloch