Feature #2569
open
- Project changed from jndn to NDN-CCL
I can see the point on this and will have to revisit with JeffT what the original motivation was for the Node. (We had some motivation for this.)
But this is a refactoring issue for an internal class. What is the motivation to expend effort on this rather than public APIs / features at this time?
Consider this interesting recent paper that claims refactoring does not increase code quality. :)
http://arxiv.org/ftp/arxiv/papers/1502/1502.03526.pdf
I created this issue for jndn, as it applies specifically there. It is not related to NDN-CCL.
Without code refactoring, we would be using DOS6.1/windows 3.11, or something of the sort :). I understand that not all refactorings have benefits, but we should not simply say that because this is implemented as it is we shouldn't change it. The current internal implementation (Face/Node) is simply adds an additional layer of indirection (Face methods redirect to Node), adding additional complexity and potentially introducing issues when something in face needs to be modified.
- Assignee set to Anonymous
- Priority changed from Normal to Low
JeffT will document why this exists across NDN-CCL and what the long-term plan is for using it. Then we can discuss.
Also available in: Atom
PDF
Updated by 
Updated by