NFD » ndn-cxx

After this task we no longer going to have "ndncatchunks3" tool, which will only exist as an example. Are you sure that we do not need such tool?

No. In fact, I think I would prefer to keep the final applications under tools; they are somewhat analogous to wget.

The old programs are broken. No one should be using them.

The fixed programs are useful as tools.
However, they shouldn't appear in ndn-cxx, given that ndn-tlv-peek and ndn-tlv-poke are in NFD.

I won't object if those programs are added as tools into NFD repository, but they still need to appear as examples in ndn-cxx.

I don't like the idea of having the same code in both ndn-cxx/examples and in NFD's tools. By definition, it doubles the maintenance load (both coding and reviewing) when something inevitably breaks.

There are a number of other tools in ndn-cxx/tools. Mostly ndnsec related things, but there's also tlvdump. Should these also be moved to NFD/tools? What distinguishes a ndn-cxx tool from an NFD tool?

NFD/tools is almost exclusively programs that only work with NFD and seems like the wrong place to put a retrieval client/server (or any of the ndn-cxx/tools).

This matter deserves a broader discussion on nfd-dev mailing list. Please post a message on nfd-dev and I'll reply there.

Steve DiBenedetto wrote:

There are a number of other tools in ndn-cxx/tools. Mostly ndnsec related things, but there's also tlvdump. Should these also be moved to NFD/tools? What distinguishes a ndn-cxx tool from an NFD tool?

There are only these two: ndnsec (I'll move all header files under ndnsec-src/ later) and tlvdump. ndnsec is entirely about security library, which is irrelevant to NFD and manages security. tlvdump is about packet format and also not exactly relevant to NFD.

cat/putchunks is kind of irrelevant to either, so I have no strong opinion on where they should go. If they are general enough, they can be both tools and there could be README under examples folder to point to other examples. If they have some specifics that needs to be adjusted for specific use, then they should go to just examples.

As for tlv-peek and tlv-poke. I would move them to the library from NFD, as they more related to the library then NFD.

Steve DiBenedetto wrote:

I was also wondering whether the Engine classes would be useful things to have in the library itself (e.g. util/) until we have Ilya's API stuff.

This probably true. Assuming there are no specifics to ndncatchunks app, these classes could go to src/util, as we already have a number of tools there. Btw. Why do they need to have "virtual run" method and be inherited from "Engine" class?

I was thinking it could be useful to have a common interface. For example, you could pass an Engine derivative (or some composition) to something else to tell the receiver how it should go about retrieving Data. We currently pass Faces around and (maybe) use Interest templates. This would be a step towards generalization.

http://gerrit.named-data.net/1581

I suggest delaying this Task until name discovery technical memo is complete.

An example is where newcomers learn how NDN applications should be designed.

One important feature illustrated in this example is how to discover the latest version.
The design of this feature should be consistent with name discovery technical memo.

I agree that this feature should be consistent with the name discovery technical memo. However, that document (as far as I can see) does not exist. In the absence of a finished document, I would prefer code review to be guided the following questions:

1. Is the current approach reasonable?
2. Is the document likely to specify a different approach for the scenario outlined in this task?

The tech memo cannot just appear out of thin air. We have to already know something about name discovery to write it. Could @Beichuan could summarize the key ideas/best practices?

The fixed programs are useful as tools.

Now we have ndn-tools repository and they can be imported as chunks tool in #3071.

Beichuan reveals at 20150727 conference call that the name discovery technical memo will be ready in August 2015.

Alex can decide whether we need this as an example, in addition to the tool in #3071.