Feature #3739
closed
Expose ControlResponse body in Controller::CommandFailCallback
Added by Junxiao Shi over 8 years ago.
Updated over 8 years ago.
Description
Currently, Controller::start<Command> fail callback only receives status code and message.
ControlResponse <body> should be exposed to the callback, so that the caller can inspect and take actions accordingly.
- Blocks Bug #3232: Inaccurate log message when changing FacePersistency added
This is necessary to implement #3232-12 procedure: when a client attempts to create a face but gets a conflict, the client needs to inspect the properties given in the response and decide whether to send an update.
- Status changed from New to In Progress
ndn::nfd::ControlResponse is an alias of ndn::mgmt::ControlResponse.
ControlResponse mismatches ControlCommand spec in that it expects exactly one TLV block in <body>, while the spec defines the <body> to be zero or more TLV blocks.
Then, to expose the <body>, ControlResponse should be given to Controller::CommandFailCallback.
This would require a backwards-incompatible change: even if I add a start overload to accept the old std::function<void(uint32_t code, const std::string& reason)> type, many callers are using bind([] (uint32_t) {}, _1) or similar when calling start, and they will get confused.
Thus, my plan is to:
- change
CommandFailCallback to function<void(const ControlResponse& resp)>; an internal instance of ControlResponse will be used for situations like command timeout or response validation failure
- declare
DatasetFailCallback as the old CommandFailCallback to use in fetch
I'm ok having the breaking change to have only one CommandFailCallback as function<void(const ControlResponse& resp)>.
- % Done changed from 0 to 50
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by