Feature #4581
closed
Default CanBePrefix declaration
Added by Junxiao Shi over 6 years ago.
Updated over 5 years ago.
Description
In early phase of Packet03Transition, Interest constructor sets CanBePrefix=1 by default, which matches Interest v0.2 behavior. Eventually, the default would be switched to CanBePrefix=1 (#4582).
To prepare applications for the switchover and avoid breaking applications that depend on CanBePrefix=1 being the default, this issue introduces Interest::setDefaultCanBePrefix static function.
Every application SHOULD declare its default by calling this function. If an application uses Interest constructor without declaring a default CanBePrefix setting, print a warning message to stderr once: "Interest.CanBePrefix will be set to 0 in the near future. Please declare a preferred setting via Interest::setDefaultCanBePrefix.".
- Category set to Base
- Status changed from New to In Progress
- Assignee set to Junxiao Shi
- Target version set to v0.7
- Estimated time set to 2.00 h
- % Done changed from 0 to 30
- Estimated time changed from 2.00 h to 6.00 h
https://gerrit.named-data.net/4767 adds the Interest::setDefaultCanBePrefix function.
I realize that it would be a bad idea to print the warning in Interest contructor, because that means a simple default-construction results in a warning. Thus, the warning is delayed until Interest::wireEncode.
I also realize that ndn-cxx itself cannot call Interest::setDefaultCanBePrefix, because that would conflict the application's choice and mask the application's negligence. Thus, I'll have to review all Interests expressed by ndn-cxx's mgmt security util and set CanBePrefix on a per-Interest basis, so that ndn-cxx itself does not trigger the warning.
- % Done changed from 30 to 40
- % Done changed from 40 to 60
- % Done changed from 60 to 70
- Tags set to Packet03Transition
- % Done changed from 70 to 80
ndn-autoconfig still triggers the warning... and then there are tons of NFD unit tests to fix :-/
I'm wondering if "fixing" all the test cases (i.e. adding an explicit setCanBePrefix(true/false)) is a good use of our time. We could simply wait until the default is flipped, and only then fix those tests that fail by adding setCanBePrefix(true). My assumption is that those tests will be a small fraction of the total.
ndn-autoconfig still triggers the warning... and then there are tons of NFD unit tests to fix :-/
I do not intend to fix NFD and its unit tests. NFD forwarding needs to process packets in v0.3 semantics before its tests can set CanBePrefix to either value. Before then, the warning remains with NFD.
Other programs in NFD repository should be fixed in the same way as PSync, etc.
Junxiao Shi wrote:
I do not intend to fix NFD and its unit tests. NFD forwarding needs to process packets in v0.3 semantics before its tests can set CanBePrefix to either value. Before then, the warning remains with NFD.
For forwarding tests I agree, but some warnings are triggered by tests that have nothing to do with forwarding, e.g. I've seen warnings in LinkService, Management, etc.
Junxiao Shi wrote:
https://gerrit.named-data.net/4767 adds the Interest::setDefaultCanBePrefix function.
I realize that it would be a bad idea to print the warning in Interest contructor, because that means a simple default-construction results in a warning. Thus, the warning is delayed until Interest::wireEncode.
The warning is printed twice because the static guard variable is in the scope of a function template which is instantiated twice, so you end up with two separate variables.
The warning message also lacks a trailing newline.
- % Done changed from 80 to 90
https://gerrit.named-data.net/5442 clears all CanBePrefix warnings from unit-tests-daemon.
unit-tests-core and unit-tests-rib do not trigger the warning.
unit-tests-tools will be handled in another commit.
- Start date deleted (
04/13/2018)
- Blocks Task #4582: Switch default CanBePrefix to false added
- Status changed from In Progress to Closed
- % Done changed from 90 to 100
Also available in: Atom
PDF
Updated by 
Updated by