Return-Path: 
 <commons-user-return-19556-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 58817 invoked from network); 13 Jul 2007 21:36:10 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 13 Jul 2007 21:36:10 -0000
Received: (qmail 29504 invoked by uid 500); 13 Jul 2007 21:36:07 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 29456 invoked by uid 500); 13 Jul 2007 21:36:07 -0000
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-user-help@jakarta.apache.org>
List-Post: <mailto:commons-user@jakarta.apache.org>
List-Id: "Jakarta Commons Users List" <commons-user.jakarta.apache.org>
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 29445 invoked by uid 99); 13 Jul 2007 21:36:07 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2007 14:36:06 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of rahul.akolkar@gmail.com
 designates 64.233.166.180 as permitted sender)
Received: from [64.233.166.180] (HELO py-out-1112.google.com) (64.233.166.180)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2007 14:36:03 -0700
Received: by py-out-1112.google.com with SMTP id a25so1081304pyi
        for <commons-user@jakarta.apache.org>;
 Fri, 13 Jul 2007 14:35:43 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=spAdGOhQhUtNRDLiJDNe+1xVQvxpjRNrsimlJB5SG4ZmfHDyH99AcmY/mfVZT4TpN6mvyvccc81kNQI6PMcxf+QofNEMSteGvr6s8lBdSJxsSzsxjZRGZnzfj16eIDg8LX+lx/MZMcvn0bLP9HM6Ln1fQ8/+Wbl51jltj2LfeaA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Z9W0PUKWUTwAzwtBVQPoezbUB26u9pzCR763CJ2dJRYoFCwcp0EgFaJ1JA+GjmxHx2SGOJyT3sZJehzT+qA95UBmD0euHl8JXY3bEICSiLRryjqUDuTugezbwmTq6HiYn0wJQdtlQDYAdJnHGNazDdaWkkz7GACawZn7k+ATrxs=
Received: by 10.64.242.5 with SMTP id p5mr3828026qbh.1184362542711;
        Fri, 13 Jul 2007 14:35:42 -0700 (PDT)
Received: by 10.65.186.3 with HTTP; Fri, 13 Jul 2007 14:35:42 -0700 (PDT)
Message-ID: <ce1f2ea80707131435q40f9405v1855ec135b44a8ca@mail.gmail.com>
Date: Fri, 13 Jul 2007 17:35:42 -0400
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [SCXML] Automatic forward of external events to <invoke>'d
 components ?
In-Reply-To: <cc9610990707121510r78649d9ej5365ede8f2c09f99@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <cc9610990707061043v5f4211f9ldaf63ad5a3baaea4@mail.gmail.com>
	 <ce1f2ea80707061342u69c5f51as44b510ebd4138251@mail.gmail.com>
	 <cc9610990707121510r78649d9ej5365ede8f2c09f99@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

On 7/12/07, Ingmar Kliche <ingmar.kliche@googlemail.com> wrote:
> 2007/7/6, Rahul Akolkar <rahul.akolkar@gmail.com>:
> >
> > It is my interpretation of, quoted from your reference:
> >
> > "Note that the <invoke> element may be used to invoke an external
> > SCXML interpreter to execute a different state machine. In this case,
> > the external state machine acts as a set of substates of the invoking
> > state. The behavior is thus similar to a complex state defined with
> > <state> child elements."
>
>
> Makes sense for sub machines!
>
> One would expect substates to receive all the same events.
>
>
> I had a look at the implementation of invoke again. It apears that external
> events (i.e. triggerEvents()) are used to feed events into both engines.
> parentEvents() uses it to feed external events occuring at the parent into
> the child engine and the child engine uses it to feed *.invoke.done into the
> parents engine.
>
> But I have missed how the child machine may send events during execution to
> its parent. If you also use external events (i.e. a triggerEvent) to send
> events to the parent, how would you avoid that the same event is forwarded
> again into the invoke'd machine?
>
<snip/>

Do we need to avoid it? An event dispatched using <send> (such as your
example below) would also be received similarly by a child state even
if it originated there. The invoke'd machine can ignore it.


> Also I have not found how events are automatically forwarded from the child
> to the parent. Assume I use a <send event="foo" targettype="scxml"/> within
> the child. This would let an external event occur at the child. Now - taking
> the assumption that an invoke'd child machine behaves like a complex state
> within the parent - I would assume that the external event occuring at the
> child is also fed into the parent.
>
<snap/>

Perhaps. The invoke section is greatly underspecified at this moment
(as is acknowledged on the Commons SCXML site), my hope is that the
next WD will bring some more clarity.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org