Suggested change in Template

[drjdpowell]

The first impression a new User gets of your template is the large number of wires coming out of the "Parse State Queue++".

It gives the impression that this framework is going to be hard to understand. It looks complex. Here is my suggestion of moving things around a bit:

I've

• separated the various Call/Response stuff from the original JKI-SM stuff
• made it obvious what the "Last State Response" is
• tries to use different names to distinguish between my response to someone else versus someone else's response to me (which I found very confusing at first)

[drjdpowell]

Oh, I also

• Made Init State a constant, as one wouldn't normally change that
• stopped passing the "My Response Args" into the case structure. This make it clear that we are sending them off in our response. I'm not sure why one would want to keep a copy of them, but the user can easily do that if they like.

[nevstop]

Great suggestion! It will be included in the coming release.

[nevstop]

Oh, I also

• Made Init State a constant, as one wouldn't normally change that
• stopped passing the "My Response Args" into the case structure. This make it clear that we are sending them off in our response. I'm not sure why one would want to keep a copy of them, but the user can easily do that if they like.

Here is why I passed the "My Response Args" in to case structure. If caller send sync message of "Macro: DoSomething" to callee, which is consist of several sub-states. This wire is needed to pass the actual return value from the middle state in "Action： Step3".

\\ sub-states of "Macro: DoSomething"
Action: Step1
Action: Step2 \\ return value
Action: Step3

Caller will get the return value as response for "Macro: DoSomething" after all sub-states are executed by callee.

But anyway, I agree with you that the users could easily do it by themselves. That's a corner case. I accept the change. It helps the template looks better. :)

[drjdpowell]

Idea: have "Parse State Queue" use a feedback node to save the last non-empty "My Response Args". Then Step 3 won't overwrite the return value provided by Step 2.

[nevstop]

Idea: have "Parse State Queue" use a feedback node to save the last non-empty "My Response Args". Then Step 3 won't overwrite the return value provided by Step 2.

I think it would be more appropriate to leave this decision to the users. If we do it within the framework, it may limit users' ability to modify the behavior as needed. Additionally, it could overwrite some expected empty responses.

[nevstop]

@drjdpowell It Looks better now. This could be a picture for a spot the difference game. :)