RE: SCXML: <invoke> etc.

Serge,

You are right that we need to clarify the sequence of events that are
triggered by exiting a state with an ongoing invocation.  The author
might well want to see the "State.Done" event, even if it came from a
previous invocation.  We will address this in a future draft. 

 

- Jim

________________________________

From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of Serge Voloshenyuk
Sent: Monday, May 14, 2007 3:36 PM
To: www-voice@w3.org
Subject: RE: SCXML: <invoke> etc.

 

As for me, you exaggerate problem with multiple invocations.
Developer knows about potential problem with rapid reentering and if
this is substantively for his task, he has to avoid it by using
<CancelResponse> event.




>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.


But why you introduce event <CancelResponse>?

Existence of event <CancelResponse> presumes that between cancellation
and  <CancelResponse> a lot of other events can be received from
invoking process. How must they be processed? If they must be ignored,
what purpose of <CancelResponse>? 
And IMHO what to do with this events is prerogative of developer.
What do you think about this?



 

  

________________________________

Pinpoint customers
<http://us.rd.yahoo.com/evt=48250/*http:/searchmarketing.yahoo.com/arp/s
ponsoredsearch_v9.php?o=US2226&cmp=Yahoo&ctv=AprNI&s=Y&s2=EM&b=50> who
are looking for what you sell.