Project

General

Profile

Feature #4777

Develop API for typed name components in naming convention

Added by Junxiao Shi about 1 year ago. Updated 22 days ago.

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

100%

Estimated time:
6.00 h

Description

Change/extend Name and name::Component APIs to support typed name components for segment number, version number, timestamp, and sequence number.


Related issues

Blocked by NDN Specifications - Feature #4577: Naming conventions: use typed name components instead of markersClosed

Actions
Blocks ndn-cxx - Task #5044: Switch default naming convention encoding to TYPEDNew

Actions

History

#1

Updated by Junxiao Shi about 1 year ago

  • Blocked by Feature #4577: Naming conventions: use typed name components instead of markers added
#2

Updated by Junxiao Shi about 1 year ago

  • translation missing: en.field_tag_list set to Packet03Transition
  • Status changed from New to In Progress
#3

Updated by Junxiao Shi about 1 year ago

  • % Done changed from 0 to 10

https://gerrit.named-data.net/#/c/ndn-cxx/+/5043/ patchset1 has the design. I'm using "version" as a demonstration.

#4

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.

#5

Updated by Junxiao Shi 10 months ago

  • Status changed from In Progress to Code review
  • % Done changed from 10 to 60
#6

Updated by Junxiao Shi 10 months ago

  • Status changed from Code review to Closed
  • % Done changed from 60 to 100
#7

Updated by Davide Pesavento about 1 month ago

  • Blocks Task #5044: Switch default naming convention encoding to TYPED added
#8

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 <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.

#9

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.

Also available in: Atom PDF