W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2011

RE: SCXML: sending to invoked processes.

From: Jim Barnett <Jim.Barnett@alcatel-lucent.com>
Date: Thu, 10 Feb 2011 09:03:59 -0800
Message-ID: <E17CAD772E76C742B645BD4DC602CD8103DAA86B@NAHALD.us.int.genesyslab.com>
To: "Johan Roxendal" <johan@roxendal.com>, <www-voice@w3.org>
Johan,

I think that your second solution is inherently safer.   Leaving aside everything that is happening on the SCXML side, you can never be sure how long it will take the invoked process to start running, so it is safer to wait for it to signal that it is running before communicating with it.  

 

-          Jim Barnett

 

From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Johan Roxendal
Sent: Thursday, February 10, 2011 11:41 AM
To: www-voice@w3.org
Subject: 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


					
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
					
Received on Thursday, 10 February 2011 17:05:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 February 2011 17:05:52 GMT