Re: Invoking on stable configuration but sending on entry

On Jan 20, 2014, at 21:36, Jim Barnett <1jhbarnett@gmail.com<mailto:1jhbarnett@gmail.com>> wrote:

Stefan,
  I'd like to put this on our list of candidate features for a future version of SCXML.  It's certainly worth discussion, particularly if a number of implementers feel a need for it.  However, I'd really like to get 1.0 finished, and adding something like this would delay us significantly.  Does that sound reasonable?


Perfectly reasonable
  Stefan

- Jim

On 1/20/2014 1:49 PM, Stefan Radomski wrote:
Hey there,

yes, the second <send> would not be evaluated - it was pseudo scxml to illustrate the point, but technical nitpickery is appreciated :D

Merging the information from the <send> element into the <invoke> would solve all timing issues but requires, at least for us, an unfortunate duplication of code. Maybe we could have <send> as a valid child of <invoke> to specify a list of events to be sent as soon as the invoker is available?

I don’t have a strong opinion on this and would just write our invokers to emit “I am started” events, I was hesitant as it felt like a kludge. Then again, I think that all invokers where the invoking interpreter “takes initiative” will *need* to emit these events and it might, therefore, made have sense to standardize some “invoke.success.<INVOKEID>” event.

If none supports my point, I don’t insist on further discussion.

Best regards
Stefan

On Jan 20, 2014, at 16:36, Jim Barnett <1jhbarnett@gmail.com<mailto:1jhbarnett@gmail.com>> wrote:

Stefan,
This is an interesting topic.  The group spent a lot of time discussing the timing of <invoke>.  We concluded, as David suggested, that the way to make information available as soon as the invoked process starts is to pass it as parameters.  If the invoking process needs to know when the invoked process actually starts, it's easy for the invoked process to do a send as soon as it starts.  (Then you put an event handler in the invoking process to send the event you want as soon as it gets the"I'm started" event.) We didn't make the "I'm started" event a requirement in the spec because a lot of applications don't need it.  Since it's easy to do in the markup, we decided to leave it to the application author.

David is right that an error in a delayed send will cause the onentry block to be exited as soon as the send is evaluated.  (The error event will be placed in the queue and thus not processed till later.)  The relevant language in 6.2.3 is:

 "The Processor MUST evaluate all arguments to <send> when the <send> element is evaluated, and not when the message is actually dispatched. If the evaluation of <send>'s arguments produces an error, the Processor MUST discard the message without attempting to deliver it."

Please let us know if you think this topic needs further discussion.  If you think it doesn't, or we do not hear from you by January 28th, we will proceed to publish the next version of the specification.

- Jim

On 1/20/2014 8:24 AM, David Junger wrote:

Le 20 jan 2014 à 11:15, Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de><mailto:radomski@tk.informatik.tu-darmstadt.de> a écrit :



as we continue to use SCXML for various applications, there is one deficiency that always bugged us. Consider that you have a state that will invoke something and you’d like to send some event to it right-away. You cannot use <send target=“#_invokeid”> in an onentry element as the invoker will not yet exist, it is only invoked when a stable configuration is reached (see procedure mainEventLoop in the draft). Thus forcing you to use a delay attribute.

<state id=“foo”>
 <invoke type=“something” id=“something” />
 <onentry>
   <!— this will fail as the invoker does not yet exist -->
   <send target=“#_something” event=“do.something” />

   <!— this will work as we had an empty internal queue -->
   <send target=“#_something” event=“do.something” delay=“1ms" />
 </onentry>
</state>

Is anyone else bugged by this behavior and resorted to the delayed send idiom, is there something more straight-forward or did we misinterpret the SCXML draft at some point?

If this is indeed correct behavior, maybe we could specify that an invoker *must* raise some internal event after being successfully invoked?


I think that is the correct behavior. And that delays are a bad way to handle it. In many situations, a 1ms delay would be enough. In some,  however, even 1s may not allow the interpreter to get to the point where the invocation is ready (because, yes, it should always have *started invoking* after the 1ms delay but there is no guarantee that the invocation is ready to queue events).

Besides, if you want to send instructions to an invoked session as soon as it starts, why not use the <invoke> parameters instead?

I agree that an event to indicate the invoked session is ready could be handy, and would be very easy to implement so why not.

BTW, it is my understanding that in the example you give, the second <send> wouldn't even be evaluated since the first error would crash the <onentry> block. Right? Or does the error.communication occur asynchronously even for non-delayed sends with an invalid target?

                        David


--
Jim Barnett
Genesys


--
Jim Barnett
Genesys