SCXML: sending to invoked processes.

hey, 

I'm glad we nailed that pesky history bug :)

a quick question/observation concerning invoke:

from my understanding of how the invocation of processes in an scxml document is described, <invoke> shall only happen after the <onentry> of it's parent state has fired (so that we can be certain that no raise or send target="_internal" immediately takes us out of that state). turns out, though, that this approach brings about the following confusion. 

what I would like to to do: invoke a document, then send it a "hello" event. 

this works:

<scxml xmlns="http://www.w3.org/2005/07/scxml">
<state>
<invoke id="i" 
src="code.google.com/p/pyscmxl" />
<onentry>
<send event="invoke_interact" />
</onentry> 
<transition event="invoke_interact">
<send event="hello" target="#i" />
</transition>
</state>
</scxml>



but pretty it aint. i'm forced to place an event on the external event queue in order to convince the algorithm that I'm in a stable state, thus causing invoke to initialize in the next macrostep, whereupon its ready to except my hello event. 

the intuitive approach would be to simply send that event in the parent's onentry block (a mistake I continually make), but that alway fails with an execution error because at that point, the invoke is yet to be, well, invoked. 

in order to circumvent this issue in my implementation, i force <invoke> of any type (scxml, soap, http etc.) to implicitly signal that they're ready for interaction by way of an init.invoke event to their parent's external queue. so the doc above would instead be:

<scxml xmlns="http://www.w3.org/2005/07/scxml">
<state>
<invoke id="i" 
src="code.google.com/p/pyscmxl" />
<transition event="init.invoke.i">
<send event="hello" target="#i" />
</transition>
</state>
</scxml>



prettier, but non-standard. an additional benefit relates to a previous question I posed to this list – whether the fetching of <invoke src="" documents should be synchronous or not: it doesn't matter, so long as they report they're readiness.

I guess I wonder if I should prepare to abandon my solution, if the first solution above is the preferred one, or if there is some third solution that you would care to share?

thanks,
Johan Roxendal