Project

General

Profile

Feature #4570

Redesign Name::getSuccessor

Added by Junxiao Shi over 2 years ago. Updated about 2 years ago.

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

100%

Estimated time:
2.00 h

Description

Name::getSuccessor returns the "successor" of a name.
As of ndn-cxx 0.6.1, this is defined as:

   *  The successor of a name is defined as follows:
   *
   *      N represents the set of NDN Names, and X,Y ∈ N.
   *      Operator < is defined by canonical order on N.
   *      Y is the successor of X, if (a) X < Y, and (b) ∄ Z ∈ N s.t. X < Z < Y.
   *
   *  In plain words, successor of a name is the same name, but with its last component
   *  advanced to a next possible value.
   *
   *  Examples:
   *
   *  - successor for / is /%00
   *  - successor for /%00%01/%01%02 is /%00%01/%01%03
   *  - successor for /%00%01/%01%FF is /%00%01/%02%00
   *  - successor for /%00%01/%FF%FF is /%00%01/%00%00%00

With ImplicitSha256DigestComponent and typed name components (#4526) in Packet03Transition, the implementation and examples no longer match the definition.
According to the definition,

  • successor for / is /sha256digest=00000000000000000000000000000000.
  • successor for /sha256digest=ffffffffffffffffffffffffffffffff is /2=....
  • all other cases: the last component does not change type.

Related issues

Blocked by ndn-cxx - Feature #4526: Recognize typed name componentsClosedJunxiao Shi

Actions
#1

Updated by Junxiao Shi over 2 years ago

  • Blocked by Feature #4526: Recognize typed name components added
#2

Updated by Junxiao Shi over 2 years ago

  • Description updated (diff)

While it is trivial to update the implementation, I doubt the necessity of Component::getSuccessor and Name::getSuccessor functions.

From #1677-1:

Successor of name is needed by repo-ng to handle rightmost selector.

Packet Format v0.3 removes ChildSelector, so CS and repo index do not need to handle rightmost selector.
Is there any other use case? If not, I propose to deprecate and eliminate getSuccessor.

#3

Updated by Davide Pesavento over 2 years ago

Should this be fixed for 0.6.2?

#4

Updated by Junxiao Shi over 2 years ago

Should this be fixed for 0.6.2?

This does not block v0.6.2 release. The problem is not caused by the introduction of typed name components. It existed since ImplicitSha256DigestComponent, and nothing is noticably broken so far.

#5

Updated by Junxiao Shi about 2 years ago

  • Status changed from New to In Progress
  • Assignee set to Junxiao Shi
#6

Updated by Junxiao Shi about 2 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 100
#7

Updated by Junxiao Shi about 2 years ago

  • Status changed from Code review to Closed
#8

Updated by Junxiao Shi about 2 years ago

  • Blocked by Feature #4658: Encode and decode Interest ApplicationParameters added
#9

Updated by Junxiao Shi about 2 years ago

  • Status changed from Closed to In Progress
  • % Done changed from 100 to 50

Reopen because #4658 defines TLV-TYPE 2 as InterestParametersSha256DigestComponent, which necessitates another update of getSuccessor logic.

#10

Updated by Junxiao Shi about 2 years ago

  • % Done changed from 50 to 70
  • Estimated time changed from 1.00 h to 2.00 h

https://gerrit.named-data.net/4891 recognizes InterestParametersSha256DigestComponent

#11

Updated by Junxiao Shi about 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 70 to 100
#12

Updated by Davide Pesavento about 2 years ago

  • Blocked by deleted (Feature #4658: Encode and decode Interest ApplicationParameters)
#13

Updated by Davide Pesavento about 2 years ago

  • Status changed from Resolved to Closed
#14

Updated by Davide Pesavento about 2 years ago

  • Tags set to Packet03Transition

Also available in: Atom PDF