Project

General

Profile

Actions

Feature #3739

closed

Expose ControlResponse body in Controller::CommandFailCallback

Added by Junxiao Shi over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Management
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

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.


Related issues 1 (0 open1 closed)

Blocks NFD - Bug #3232: Inaccurate log message when changing FacePersistencyClosedYanbiao Li09/30/2015

Actions
Actions #1

Updated by Junxiao Shi over 7 years ago

  • Blocks Bug #3232: Inaccurate log message when changing FacePersistency added
Actions #2

Updated by Junxiao Shi over 7 years ago

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.

Actions #3

Updated by Junxiao Shi over 7 years ago

  • 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
Actions #4

Updated by Alex Afanasyev over 7 years ago

I'm ok having the breaking change to have only one CommandFailCallback as function<void(const ControlResponse& resp)>.

Actions #5

Updated by Junxiao Shi over 7 years ago

  • % Done changed from 0 to 50
Actions #6

Updated by Junxiao Shi over 7 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100
Actions #7

Updated by Junxiao Shi over 7 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF