NFD » ndn-cxx

https://gerrit.named-data.net/#/c/ndn-cxx/+/5043/ patchset1 has a convention argument in each API, which could cause difficulty for eventual removal.

patchset3 is an alternate design that only offers global settings for encoding and decoding conventions. While it is easier for eventual removal, every part of an application would have to adopt the same convention at least for encoding. Suppose for some reason PSync wants REV2 (to talk to other nodes using new convention) and management client wants REV1 (to talk to legacy application), an application using both would have to switch the global encoding convention setting back-and-forth, and won't work at all if it's multi-threaded.

https://gerrit.named-data.net/c/ndn-cxx/+/5820 attempts to print name components matching known naming conventions in an alternate format.
Before we could do that, there should be a way to print name component in <type-number>=<escaped-value> format.

URI string is used programmatically in at least two places:

• ValidatorConfig config section matches URI strings with regular expressions. Changing URI breaks existing configs.
• ndncert /CA/_PROBE/INFO packet contains JSON text that contains URI string of the CA, which could contain typed name components (version and segment are unlikely to appear, but it's possible for the CA prefix to contain a sequence number, for example). NDN packet format does not require every node to support alternate URI format (except for types 0x01, 0x02, and 0x08), so making this change will break backwards compatibility.

The API could look like:

name.toUri(); // prints generic format
name.toUri(false); // prints generic format
name.toUri(true); // prints alternate format

It's very important to print generic format in the default setting, in order to maintain backwards compatibility.

I don't disagree with adding a boolean flag to toUri(). However, as decided at today's NFD call, that shouldn't block merging the aforementioned change.

OTOH, I do disagree with the default value of false for that flag, which would mean "do not use the alternate encoding". Name components with type 1, 2, and 8 are already using the alternate encoding today, and have been doing that for a very long time. Changing that would break a lot more things compared to switching the typed name components used in naming conventions to the new alternate format (I think we can assume that most, if not all, apps are still using the marker-based conventions). Moreover, the alternate URI format is a lot more human-friendly so it should be the default.

https://gerrit.named-data.net/c/ndn-cxx/+/5880 enables selection between canonical vs alternate URI representations.
Apart from a boolean flag, the default is controlled by NDN_NAME_ALT_URI environment variable: if it's set to '0', use canonical URI; otherwise, use alternate URI.
The reason for introducing NDN_NAME_ALT_URI is that, it would take a lot of effort to add URI representation choice to every app, but setting an environment variable is much easier in a deployment.