NFD » ndn-cxx

At 20150803 conference call, Yingdi reveals the plan of using a synchronous API:

1. The API is synchronous, ie. will return the requested item (eg. certificate).
2. Inside the function call, a default-constructed Face will be used to express the Interest, and then .processEvents() will be called on that Face. This ensures no other calls can be executed on the same io_service.
3. The Interest will have a "relative small" InterestLifetime to reduce blocking issue.

There are 3 issues in this plan:

• A default-constructed Face may not be able to connect to a forwarder. An application may explicitly pass a Transport instance to Face constructor in order to talk to a forwarder, in an environment where the default-constructed Face does not work.
• Two faces are opened on NFD side, doubling the Face maintenance overhead.
• No matter how short the InterestLifetime is, it affects application performance by blocking a thread.

I do not disagree with a synchronous API as a short term solution.
But the final solution should be a completely asynchronous API from KeyChain to Pib and Tpm (including #2488).

Yingdi agrees at 20150817 conference call that the final solution should be asynchronous because it involves network operation.