repo-ng

I need some help regarding the task. The description is not very clear to me. I will try to break it down according to my understanding:
First, Repo will serve certificate to the other nodes. For that repo will store the certificates some where (CertificateCache?) and set interest filter on the certificate's common prefix.
Second, Repo needs to register prefix for the data prefixes here : https://github.com/named-data/repo-ng/blob/master/src/repo.cpp#L148.

I am not aware of the discussion related to PIB service. So can't relate.

I think you're over-thought the issue. Right now repo registers with local NFD a set of prefixes specified in the configuration file. With this issue (which should be an option to enable), the repo should register prefixes that correspond to all data packets stored in repo (could be many prefixes, but it's ok). So, you don't need to use any new data structures, rather differently handle the startup and add additional logic on when data packet is added to the storage and removed from the storage.

Registering the exact name of each stored Data packet would not supoort the certificate use case, because the Interest to retrieve a certificate is usually a true prefix of the Data name.
Without loss of generality, I would envision:

• a configuration option that determines the granularity of prefix registration, ie "register Data name minus last k components"
• alternatively, a parameter in repo insertion command that determines the granularity, along with a database field storing this parameter

The program logic needs to ensure the prefix registration is not withdrawn until the last Data requiring such registration is deleted.

add additional logic on when data packet is added to the storage and removed from the storage.

Hint: given ReadHandle is reponsible for data prefix registration, RepoStorage needs to emit signals upon Data insertion and deletion, and ReadHandle shall react to such signals.

Caution:

• If a Data is inserted and quickly deleted, #2720 may affect the unregistration.
• If there are many registrations upon startup, #1589 and #2174 may cause registration failures until #2293 is implemented.