NFD » ndn-cxx

Alex approves this feature at 20151103 conference call.

It appears that NFD build is still failing even if backwards-compatibility is enabled.
https://travis-ci.org/yoursunny/ndn-cxx-breaks/builds/90984603

The build failure is caused by NFD assuming <ndn-cxx/management/nfd-local-control-header.hpp> includes some other headers, but they are no longer included now.

One choice is to add these includes back into <ndn-cxx/management/nfd-local-control-header.hpp> even if they are not being used by that header.

The other choice is to keep ndn-cxx change intact but start working on #3339, because what other headers <ndn-cxx/management/nfd-local-control-header.hpp> includes is not part of ndn-cxx public API.

I'm unsure which choice is better.

Let's work on #3339 right away.

Since NFD is the only affected project and will be fixed right away, shall I put on DEPRECATED macro right now, or even delete LocalControlHeader altogether?

My opinion is to put DEPRECATED, but not delete (I have a program that uses LocalControlHeader API, so others may have as well).

Junxiao Shi wrote:

It appears that NFD build is still failing even if backwards-compatibility is enabled.
https://travis-ci.org/yoursunny/ndn-cxx-breaks/builds/90984603

The build failure is caused by NFD assuming <ndn-cxx/management/nfd-local-control-header.hpp> includes some other headers, but they are no longer included now.

This clearly shows the danger of relying on transitive include dependencies (on library headers; intra-application transitive deps are usually fine). I think I already argued in the past that we should not rely on this, it's basically the same thing as using undocumented or private APIs.

One choice is to add these includes back into <ndn-cxx/management/nfd-local-control-header.hpp> even if they are not being used by that header.

The other choice is to keep ndn-cxx change intact but start working on #3339, because what other headers <ndn-cxx/management/nfd-local-control-header.hpp> includes is not part of ndn-cxx public API.

I agree with Alex on this.

My opinion is to put DEPRECATED, but not delete (I have a program that uses LocalControlHeader API, so others may have as well).

This sounds like the safest option, but I'm fine either way.

NFD has been fixed in #3339.

ndn-cxx-breaks https://travis-ci.org/yoursunny/ndn-cxx-breaks/builds/91243492

integ http://redmine.named-data.net/attachments/download/495/20151115170031.tgz (note: remote_register is expected failure)

Deprecation notice is sent to ndn-lib nfd-dev.

No further waiting is necessary because the Change is backwards-compatible (unless a project is relying on undocumented API such as transitive include dependencies, which is unsupported).