NFD

I think the important thing to get right in #4467 is the following: "design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added".
I'm not sure if I can agree with the current direction of "manually" adding every single counter (+getter/setter) to ndn-cxx.

If you only concern is implementing getter and setter: this can be automated.
I wrote (and lost) a script that takes variable declarations (e.g. uint64_t m_nInInterests;) and generates has+get+set+clear functions.

Another potential problem is that, in the long run, it might not be a good idea to keep adding lots of (rarely used) counters to FaceStatus, as it makes retrieving the status and the list of faces more and more expensive (the linux kernel faced a similar problem some time ago).

Modern web technology's answer to this problem is GraphQL.
Maybe we should move away from TLV and adopt GraphQL+JSON.

Junxiao Shi wrote:

I think the important thing to get right in #4467 is the following: "design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added".
I'm not sure if I can agree with the current direction of "manually" adding every single counter (+getter/setter) to ndn-cxx.

So Can you suggest some idea to achieve this? Is it a good idea to use a container like a map or (key, value) pair for counters.

If you only concern is implementing getter and setter: this can be automated.
I wrote (and lost) a script that takes variable declarations (e.g. uint64_t m_nInInterests;) and generates has+get+set+clear functions.

Another potential problem is that, in the long run, it might not be a good idea to keep adding lots of (rarely used) counters to FaceStatus, as it makes retrieving the status and the list of faces more and more expensive (the linux kernel faced a similar problem some time ago).

Modern web technology's answer to this problem is GraphQL.
Maybe we should move away from TLV and adopt GraphQL+JSON.

I will think about GraphQL

Junxiao Shi wrote:

I think the important thing to get right in #4467 is the following: "design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added".
I'm not sure if I can agree with the current direction of "manually" adding every single counter (+getter/setter) to ndn-cxx.

If you only concern is implementing getter and setter: this can be automated.

No, that's not my concern at all. What I want to avoid is having to modify the library for every new counter introduced. It's not "just" the getter/setter but all the hand-written serialization/deserialization code. And it's not even about the "hand-written" part, but about the fact that the library needs to be aware of the new counter type.

Another potential problem is that, in the long run, it might not be a good idea to keep adding lots of (rarely used) counters to FaceStatus, as it makes retrieving the status and the list of faces more and more expensive (the linux kernel faced a similar problem some time ago).

Modern web technology's answer to this problem is GraphQL.
Maybe we should move away from TLV and adopt GraphQL+JSON.

Maybe, although GraphQL seems overkill, I supported moving away from TLV for management years ago. But here I was merely saying that extracting all the detailed counters should be a separate management API endpoint, or enabled via a flag on the existing face status endpoint.

we should design an extension to the Management protocol that doesn't require changing ndn-cxx every time a new counter is added.

Part of #4600 is to switch Management encoding from TLV to CBOR, fulfilling this desire.