<tt><font size=2>Clint Byrum <clint@fewbar.com> wrote on 10/30/2013
01:42:53 PM:<br>
> ...<br>
> <br>
> The engine should store _all_ of its state in a distributed data store<br>
> of some kind. Any engine should be aware of what is already happening<br>
> with the stack from this state and act accordingly. That includes
the<br>
> engine currently working on actions. When viewed through this lense,<br>
> to me, locking is a poor excuse for serializing the state of the engine<br>
> scheduler.</font></tt>
<br>
<br><tt><font size=2>I agree.  I reached a similar conclusion this
spring when thinking through the multi-engine issue for my group's work.</font></tt>
<br><tt><font size=2><br>
> It feels like TaskFlow is the answer, with an eye for making sure<br>
> TaskFlow can be made to work with distributed state. I am not well<br>
> versed on TaskFlow's details though, so I may be wrong. It worries
me<br>
> that TaskFlow has existed a while and doesn't seem to be solving real<br>
> problems, but maybe I'm wrong and it is actually in use already.</font></tt>
<br>
<br><tt><font size=2>As Zane pointed out when I asked, there is a difference
between orchestration and workflow: orchestration is about bringing two
things into alignment, and can adapt to changes in one or both along the
way; I think of a workflow as an ossified orchestration, it is not so inherently
adaptable (unless you write a workflow that is really an orchestrator).
 Adaptability gets even more important when you add more agents driving
change into the system.<br>
<br>
Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>