Generalizing the Path class in order to model multicast paths

[bocattelan]

This is how I modelled multicast paths. This format is used by the multicast analyses that are being developed for the tool (Explicit Intermidiate Bounds, Multicast Feed Forward and Unicast Transformation).

A multicast path is a collection of unicast paths that share the same source. Each of these unicast paths can be uniquely identified by an "id", which is an integer. This "id" is used in the class methods to access the unicast paths.
For this I implemented an inner class called UnicastPath, which represents these unicast paths inside a multicast path.

Ex: path.getServers() -> used for unicast flows
path.getServers(id) -> will call getServers in the UnicastPath identified by "id"

[matyesz]

I think this will be a temporal fix as there will be a new approach to the model in v2.5. In the new model we will have a flow that will have multiple paths with the same source we could also call it a channel.

[sbondorf]

After some time has passed, let me try to sum up what we have and where we want to go. Thus, we how to go on best. To me, this seems to be a situation where we need to balance academic and software development interests (more on that later after "Second").

First, thanks for getting into the code @matyesz. I believe these hints for improvements are not only valid for this change set but also apply to existing code that I wrote and published (I am looking at the Network class in particular). Stability improvements of this kind are welcome and not to hard to include, so this is not really a show-stopper.

Second, being a temporary solution sounds better than none at all in this period of time. Therefore, I would not consider this a show-stopper either. More so, we used @bocattelan's version for evaluations in upcoming publications. Our academic aim is to allow for reproducibility, i.e., to publish the code we used to produce our results. In fact, this is not the code to-be released to catch up with publications.
On the other hand, having a feature in v2.4 that will be stripped out of v2.5 due to the other plan @matyesz mentioned, is not a good idea either. Neither do I want to postpone v2.5 for too long. It has a lot of changes already and after adding the affine curve stuff (currently in progress), we could release it.
Thus, this is my suggestion, please provide your comments:
As soon as we release v2.5, v2.4 will go into an "end of life; unstable publication reproducibility changes only" state.
From a technical point of view, that means we branch master into v2.4, merge v2.5 into master, and merge changes like this into the new v2.4 branch.

[sbondorf]

By the way the "unstable" might be a too strong statement, features that stabilize there can of course be forward ported to newer releases. In particular if alternative/competing plans do not work out as expected. For example, handling exceptions is probably an area all of the current code base can benefit form improvements.

[matyesz]

I totally agree with @sbondorf and recommend to use a static code checker tool (ie. checkstyles or bugzilla) to avoid simple coding styles that can lead to later errors. On the merging please decide as if it is needed for publications' reproducability I definiatelly agree on the merge. Perhaps we could maintain an academic branch for 'quick and dirty' solutions where I mean that a publication or conference has prio over code quality.

[sbondorf]

Static code checking is a good idea, indeed. I try to run spotbugs regularly (there's an Eclipse plugin).
You can also have Coverity Scan check your GitHub project. They run spotbugs/findbugs plus some of their own analyses. I used to do that but their software stopped working many macOS releases ago. Unfortunately, you cannot convert an old project to start checking github code. The v2.5 release seems a good time for a new Coverity Scan project.

An "academic work" branch sounds like a good idea (better than my naming proposition).
So, when v2.4 gets branched from master to keep its code in an easily accessible location, I will also create a branch from this branch. I.e., master --> v2.4 --> v2.4academic; v2.5 ==> master (where --> is the branching operation and ==> the merging). Then, we can merge this pull request into the v2.4academic branch.

[matyesz]

Sonar is the best I have ever seen. Not only code but package and dependency checks are done by the tool. Eclipse and maven plugin exist also provides a nice and easy to use web page.