Re: SCXML: <send> and <event>

Jim,
If m0 was the 'toplevel' SCXML document (i.e. a document no <invoked>
by any other document), then <send event="e"> in m0 would 'send' the
event back to the interpreter, to be handled (or not handled) there in
an (I suppose) implementation dependent manner. It thus becomes a way
for SCXML to communicate with with its interpreter. An implementation
could decide to _not_ handle such events, and perhaps to log a warning
if they show up. If a developer has access to the implementation of
the interpreter, or has an implementation dependent way to communicate
with the interpreter, he may want to handle them though.

- Torbjörn

On 5/15/07, Barnett, James <James.Barnett@aspect.com> wrote:
> Torbjorn,
>   That's an interesting suggestion.  What would the default behavior be for <send> in m0? What should <send event="e"> mean in m0?
>
> - Jim
>
> -----Original Message-----
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Torbjörn Lager
> Sent: Tuesday, May 15, 2007 12:29 PM
> To: www-voice@w3.org
> Subject: SCXML: <send> and <event>
>
>
> Hi All,
>
> Based on my attempts (soon to be released in Synergy SCXML-Lab) to
> make <send> and <event> behave more in accordance with the current
> draft, I have come up with couple of suggestions that deviate somewhat
> from what is said in the draft. Nothing radical, just a few small
> things.
>
> Suppose that we have three machines m0, m1 and m2, where m0 has
> invoked m1 and m1 has invoked m2 (m0 may in fact be the runtime
> environment of the SCXML interpreter, e.g. the OS), and that we are
> executing a <send> in m1. In my understanding of the current
> specification here's how we
>
>  1. add "e" to the external queue of m0:
>
>     <send event="e" target="'m0'"/>
>     <send event="e" target="_caller"/>
>
>  2. add "e" to the external queue of m1:
>
>     <send event="e"/>
>     <send event="e" target="'m1'"/>
>     <send event="e" target="_self"/>
>
>  3. add "e" to the external queue of m2:
>
>     <send event="e" target="'m2'"/>
>
>  4. add "e" to the internal queue of m1:
>
>     <event name="e"/>
>
> Based on my experiences implementing an playing with this, I have a
> couple of comments:
>
> 1. My first comment is simply terminological. I think the term
> "external queue" is confusing. I would much prefer the term "input
> queue" instead, which more clearly describes its role.
>
> 2. I think the draft gets the default for 'target' wrong. In my view
> it makes more sense to make '_caller' the default here, since
> returning events from an invoked machine to an invoking machine (which
> could be the runtime environment of the SCXML interpreter) is probably
> a common thing to do, and, as far as I can see, a machine adding
> events to its own *external* queue probably isn't very common. (It is
> of course important for a machine to be able to add events to its own
> *internal* queue.)
>
> 3. As I have said in an earlier name, I don't think "event" (as in
> <event>) is a good name for a piece of executable content. I'm
> suggesting using "raise" instead, with an attribute 'event', in
> analogy with <send>.
>
> So, here's how I suggest it should work. In m1, to
>
>  1. add "e" to the input queue of m0:
>
>     <send event="e"/>
>     <send event="e" target="'m0'"/>
>     <send event="e" target="_caller"/>
>
>  2. add "e" to the input queue of m1:
>
>     <send event="e" target="'m1'"/>
>     <send event="e" target="_self"/>
>
>  3. add "e" to the input queue of m2:
>
>     <send event="e" target="'m2'"/>
>
>  4. add "e" to the internal queue of m1:
>
>     <raise event="e"/>
>
>
> Regards,
> Torbjörn
>

Received on Tuesday, 15 May 2007 20:48:28 UTC