Community
Participate
Working Groups
In each transition code block, you have access to a variable called rtport which is a pointer to the (common base class) RTProtocol for the port on which the message which triggered this transition was received. The primary purpose of rtport is for replying to messages: rtport->ack().reply(); Also, apparently this is possible: return RTOutSignal( &port, signal, msg->getData(), msg->getType() ).send();
Tuleap work item 12876
Change milestone to 1.0.1 as invoke/reply is not part of 1.0.
Scope too large for a bugfix - additional functionality to add. Priority of 0 in Tuleap. Moving to "Future".
(In reply to Ernesto Posse from comment #2) > Change milestone to 1.0.1 as invoke/reply is not part of 1.0. (In reply to Charles Rivet from comment #3) > Scope too large for a bugfix - additional functionality to add. > Priority of 0 in Tuleap. > Moving to "Future". Just to clarify: The use of rport is not necessarily limited to the use of synchronous message passing using invoke/reply, but also for responding to ordinary asynchronous messages. So I am not sure if the original reason for not including rtport in 1.0 due to that invoke/reply is not included in 1.0 was really a valid argument. With that said, maybe rtport should be not be included in 1.0 anyway. But the reason for not including it should not really be based on whether invoke/reply is included or not, since rtport is useful in other scenarios as well.
(In reply to Peter Cigehn from comment #4) > (In reply to Ernesto Posse from comment #2) > > Change milestone to 1.0.1 as invoke/reply is not part of 1.0. > > (In reply to Charles Rivet from comment #3) > > Scope too large for a bugfix - additional functionality to add. > > Priority of 0 in Tuleap. > > Moving to "Future". > > Just to clarify: The use of rport is not necessarily limited to the use of > synchronous message passing using invoke/reply, but also for responding to > ordinary asynchronous messages. So I am not sure if the original reason for > not including rtport in 1.0 due to that invoke/reply is not included in 1.0 > was really a valid argument. > > With that said, maybe rtport should be not be included in 1.0 anyway. But > the reason for not including it should not really be based on whether > invoke/reply is included or not, since rtport is useful in other scenarios > as well. Agreed. The move to future is not based on invoke/reply, but on the factors I listed in my comment (plus the workaround, if it still works). This can be reconsidered if any of those factor change.
