Re: SCXML: <invoke> etc.

Jim,
I see the problem and I do agree that generating and tracking a unique
ID for each invocation seems to fix it. But we found, as I recall it,
that the use of a machine generated ID has the unfortunate consequence
that it leaves the developer with nothing to match on. Or are you
implying that a combination of an explicit user defined ID and a
machine generated ID would work - using the former for getting
something to match on, and the latter for book keeping purposes? Hmm,
I don't have time to revisit this issue right now, but if this is what
you are saying, it kind of sounds like it might work...
- Torbjörn

On 5/10/07, Barnett, James <James.Barnett@aspect.com> wrote:
> Torbjorn,
>   One further comment on <invoke>.  You mention below that allowing multiple <invoke> tags in one state would rule out letting the state's ID serve as the ID of the invoked component.  It is not completely correct to use the state ID even in the current implementation, and you will note that the algorithm requires the generation of a unique ID for each invocation.
>
> The reason for this is the following example (which someone else pointed out to us):  suppose state S1 contains an <invoke> tag and the system enters S1 and then leaves and re-enters it rapidly.  When the system leaves S1, it must cancel the ongoing invocation, but it is always possible that the cancellation message could cross paths with the response "S1.done" from the invoked component.  So if the system receives "S1.done" right after firing the <invoke> on its second entry into S1, it does not know which invocation the event is a response to - if the "S1.done" was sent as the result of the first invocation, it should be ignored, should not trigger <finalize> processing and not added to the event queue, but if it was sent as the result of the second invocation, it should trigger <finalize> and be added to the event queue.
>
> I don't know how likely this sequence of events is in practice, but it strikes me as logically compelling, which is why the current algorithm requires that a unique ID be generated and tracked.  (Note that the unique ID is distinct from the state ID, but can be mapped to it and that processing in Wait_External_Event_Phase and Exit_State_Phase checks for an ID match.)  Of course, there could well be a bug in our logic somewhere, but if so I'm sure you'll find it...
>
> - Jim
>
> -----Original Message-----
> From: Torbjörn Lager [mailto:lager@ling.gu.se]
> Sent: Thursday, May 10, 2007 11:01 AM
> To: www-voice@w3.org
> Cc: Barnett, James
> Subject: Re: SCXML: <invoke> etc.
>
> Jim,
>
> Thanks for the prompt response! Your explanation confirmed one of the
> readings I had of the current specification of <invoke> - and I do find
> this reading very reasonable. However, there are still passages that
> confuses me, in particular passages dealing with <finalize>.  I do
> understand _one_ role that <finalize> is supposed to have: to update the
> datamodel in the invoking machine with values returned in events coming
> from the invoked machine. But it appears to me that this role could
> equally well be filled by (possibly targetless) transitions from the
> state in which the <invoke> is embedded. That is, instead of:
>
>  <state ...>
>     <invoke ...>
>        <finalize>
>           ... exec. content ...
>        </finalize>
>     </invoke ...>
>  </state ...>
>
> we could have:
>
>  <state ...>
>     <invoke .../>
>     <transition ...>
>        ... exec. content ...
>     </transition ...>
>  </state ...>
>
> Or am I missing something?
>
> There are some passages that seem to suggest that <finalize> could have
> another role as well. In section 6.1:
>  "The finalize code can thus be thought of as a preprocessing stage that
> applies before the event is added to the event queue."
>
> Also, in section 6.1.2:
>  "<finalize>. Optional element containing executable content to massage
> the data returned from the invoked component. ..."
>
> The wording here makes it sound like <finalize> is able to _change_ an
> event returned from the invoked machine - to transform it into another
> form - before it 'leaves' the <invoke> element. Do you have something
> like this in mind as well? I think that the idea of <finalize> as a kind
> of "event translator" or "data transformer" - has a certain appeal to
> it. There may be situations where a developer decides to invoke
> something which generates some events that just aren't useful, or even
> harmful, and that he would like to stop before the rest of the machine
> can see them. And there may be events that he wants to transform into
> another form. On the other hand, this could be done by means of
> transitions as well - transitions that catch the events in question
> before they go any further, and that possibly also send new events, with
> data payloads based on computations involving the original events.
>
> This would then reduce the <finalize> element to "syntactic sugar",
> wouldn't it? (I have nothing against syntactic sugar - I'm all for it -
> but the specs should then clearly state that it *is* sugar, and provide
> a translation into the 'kernel language'.)
>
> Another thing: It seems to me that you could allow states to have more
> than one <invoke> child, and that this might be very useful. (This is
> however not compatible with the idea of letting the state´s ID serve as
> the ID of the invoked component, but that could presumably be handled in
> another way.)
>
> Regards,
> Torbjörn
>
>
>
>
>
>
>
>
>
> Barnett, James wrote:
> > Torbjorn,
> >  The chances of us being last call in September are 0, (in part because of all the problems you're helping us discover.)  The next draft will most likely not be Last Call, but I don't know when it will be out.
> >
> > I agree that the <invoke> section needs tightening up, but in any case the intent is that the invoked machine shares _nothing_ with the invoking one - the only communication between the two state machines is via data a) passed in <param>, b) explicitly sent in <send> elements or c) returned (in a platform-specific way upon the exit of the invoked machine).  So the event queue should not be shared.
> >
> > Given clause b above, you probably do want to set up some sort of mechanism whereby the invoked machine can <send> events back to the invoking machine, and vice versa.  (When you do this, you will notice another gap in the spec, which is that there is no way for the author to get access to the SCXML session ID, which you will need when communicating between machines that are each running multiple sessions - we will fix this in the next draft of the spec.)
> >
> > - Jim
> >
> > -----Original Message-----
> > From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Torbjörn Lager
> > Sent: Thursday, May 10, 2007 8:12 AM
> > To: www-voice@w3.org
> > Subject: SCXML: <invoke> etc.
> >
> >
> > Hi,
> >
> > The specification of <invoke> and related elements is quite vague and
> > ambiguous in the current draft. In my current implementation (at
> > <http://www.ling.gu.se/~lager/Labs/SCXML-Lab/>), if an SCXML state
> > machine invokes (e.g.) another SCXML state machine, the external queue
> > of the latter is simply completely shared with the external queue of the
> > former. This is probably not the way it should be done, and probably not
> > what you have in mind. Right?
> >
> > I saw that the last call working draft of SCXML is planned in September.
> > Any chances you could leak something about your current thoughts on
> > <invoke> etc.- if you have any - before then?
> >
> > Regards,
> > Torbjörn
> >
>

Received on Friday, 11 May 2007 11:23:57 UTC