You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To implement full support for AIP 2.0, we need to add support for RFC0317 Please Ack to ACA-Py. The feature needs to support both types of requested ACKs -- RECEIPT and OUTCOME.
The OUTCOME part of this RFC is tricky, I think. AFAIK, the framework must detect when the "outcome" is produced, which is a context-specific notion, dependent on the protocol being run and the current state of the protocol. I believe (although I'm not sure it is clear in the RFC) that "outcome" means that the state of the protocol proceeds to the next state based on the actions of the recipient of the pleaseAck decorator.
In implementing this feature, those issues must be addressed. It would be nice to have this feature implemented independent of specific protocols -- detected and handled by the protocol manager component. As noted, that is relatively easy to do for a RECEIPT request, but trickier for an OUTCOME.
The text was updated successfully, but these errors were encountered:
Hello @swcurran . I've created a PR (#2540) that could become a start point in the discussion about please_ack support in ACA-Py. I would appreciate if someone takes a look at it. Thanks.
To implement full support for AIP 2.0, we need to add support for RFC0317 Please Ack to ACA-Py. The feature needs to support both types of requested ACKs --
RECEIPT
andOUTCOME
.The
OUTCOME
part of this RFC is tricky, I think. AFAIK, the framework must detect when the "outcome" is produced, which is a context-specific notion, dependent on the protocol being run and the current state of the protocol. I believe (although I'm not sure it is clear in the RFC) that "outcome" means that the state of the protocol proceeds to the next state based on the actions of the recipient of thepleaseAck
decorator.In implementing this feature, those issues must be addressed. It would be nice to have this feature implemented independent of specific protocols -- detected and handled by the protocol manager component. As noted, that is relatively easy to do for a
RECEIPT
request, but trickier for anOUTCOME
.The text was updated successfully, but these errors were encountered: