Develop API for typed name components in naming convention
name::Component APIs to support typed name components for segment number, version number, timestamp, and sequence number.
Updated by Junxiao Shi about 1 year ago
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.
Updated by Junxiao Shi 23 days ago
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
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.
Updated by Davide Pesavento 22 days ago
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.