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 who are looking for what you sell.