NFD

Vince, have you implemented the RibEntry data structures? If so, could you give me a pointer to it?

BTW, probably the implementation of RibEntry data structure should be a separate task, so that tasks #1749 and #1662 can proceed in parallel?

Yes, I am currently implementing the RibEntry data structure in ndn-cxx. I will create a new task for the implementation.

As of right now, you will not be able to use segment publisher at all (since it is part of daemon/).

One option is to move it to core/ and make templated, so it can be used with AppFace (in NFD internally) and anywhere else with ndn::Face. Junxiao, does this sound reasonable or we should do something else?

I agree with proposal in note-11.

No objection to moving SegmentPublisher to core, but it relies on AppFace because SegmentPublisher::publishSegment calls AppFace::sign (only AppFaces have an associated keychain). If you want it to use a generic Face, then you will need provide the keychain some other way.

What if we make KeyChain global? Like we do with scheduler and io_service?

That may be an option. I think the current implementation was part of the effort to avoid global things to help future porting to ndnsim. Just keep in mind that some management things will also need corresponding tweaks:

• ManagerBase::sendResponse (2 args)
• StatusServer::onInterest
• NotificationStream::postNotification (should this also be moved to core?)

Alternative is to explicitly provide KeyChain in constructors of all managers (technically, there should be one KeyChain in the application) and streams... This seems to be much more intrusive change and not sure how much beneficial...

Agreed. I don't have any objections to making the keychain global like the scheduler and io service. My intention in #15 was to mention the original design choice.

I disagree with having a global KeyChain.
I also withdraw the agreement with note-11.
It's okay to have a global Scheduler, because it deals with relative time only, which is same across nodes (unless we model hardware clock drift which is generally invisible).
It's unacceptable to have a global key chain, because the possession of keys on different nodes are different.

To use SegmentPublisher with both AppFace and ndn::Face:

1. rename AppFace to AppFaceBase, abstract sending and receiving to InternalFace; AppFaceBase constructor takes a KeyChain, and can sign Data with the KeyChain (or simply has a getKeyChain method
2. change SegmentPublisher to take AppFaceBase
3. create a new AppFace class which derives from AppFaceBase; its constructor takes ndn::Face and KeyChain, and passes the KeyChain to base class constructor, but uses the ndn::Face for sending and receiving

20140716 conference call decides that nfd::AppFace shouldn't own a KeyChain.
Instead, a KeyChain is created in main.cpp and passed to managers.

This makes note-11 feasible without adding a global KeyChain.

Which task corresponds to these changes in Note #19? Vince is willing to work on it if no one is assigned to work on that.

Changes in note-19 could be completed as part of this Task.