[Discussion] Future of NFN inside ccn-lite.

[blacksheeep]

NFN is going to be moved to PiCN. The NFN-scala version of NFN is not very maintable.

Question:

• If NFN is completely implemented in PiCN, should we freeze a ccn-lite release with NFN support and a nfn-scala release and afterwards, should we remove NFN from CCN-lite?

• Would remove the complexity of ccn-lite forwarding.

• Would remove many IFDEFS

• Would make code more maintainable

• Better fitting the requirements of the users of ccn-lite (sensornets, multi packetformat forwarding etc.)

Please join this discussion and tell me what you think about this idea. Is there anyone how completely relies on this NFN implementation?

[mfrey]

What is the status of NFN in CCN-lite? Who is the maintainer (I assume it's you)? Do you want to maintain it? Do you think it is maintainable?

I don't know if removing NFN would significantly reduce the complexity of ccn-lite. Honestly, I would prefer to have far more unit tests (written in a well-known framework or at least some documentation about the internals of the current used systems) with mocks (so you can actually mock the behaviour of modules/components) and a build system which provides builds and runs a ton of tests before I would touch NFN.

Personally, I think that one of the key issues is that CCN-lite provides different platforms but if I, as a developer, touch one part, can't really be sure that it doesn't break something else in it. Tests what actually mitigate that risk and if written well would also allow outsiders to grasp the internals of CCN-lite easier/faster.

You build something. It took time, effort and dedication and you probably have a different view what should be next (or what the key issues are)?

[blacksheeep]

I am the only one maintaining NFN. With growing features, this has become very chaotic. NFN in CCN-lite is only the forwarding plane. To execute computations, it is required to start a nfn-scala instance. This increases the complexity of the entire system -- in my opinion in an unreasonable way. Furthermore, this two components property makes it difficult to extend NFN or just simple change the NFN forwarding system, e.g. for Edge Computing (currently it is optimized for cloud computing). It always requires changes on both layers. Since they run independently, debugging is extreme complicated. PiCN is a thing to address these problems, and should be a new single component NFN implementation, while, if you need an ICN forwarder, ccn-lite is the thing to go for.

I think, removing NFN will at least improve the readability of the ccnl-fwd, since some IFDEF will go away and ageing and other stuff will become simpler (no callbacks for NFN).

If we continue the NFN development in PiCN, i think we will end up with an outdated NFN in ccn-lite, which requires additional effort to be maintained and fixed if sth. in ccn-lite changes.

[cgundogan]

IMHO, removing NFN code from CCN-lite has many advantages. As @blacksheeep pointed out, we can get rid of many #ifdefs and it makes no sense to keep unmaintained code in the code base. So, @blacksheeep, if you are certain that NFN is not going to be updated in CCN-lite, then I would also vote for a removal.

[mfrey]

@blacksheeep It's up to you? You can proactively ask somebody in your research group/community (who is using NFN in ccn-lite) if he/she wants to takeover the maintenance. If nobody wants to takeover, we should remove the code.