[Ns-developers] Cooperative ns-3 simulation with third party software via JSON-RPC

Mathieu Lacage mathieu.lacage at sophia.inria.fr
Tue Jan 20 23:42:07 PST 2009

On Tue, 2009-01-20 at 18:46 +0000, Tom Henderson wrote:

> To me, the main issues to resolve regarding merging this code are:
> - whether it meets the coding style criteria (a fixable issue)
> - whether it will be maintained/documented, and how difficult it is to
> maintain
> - how it impacts other code
> - whether and how we want to accept another build dependency

Other issues:
  - newcomers who start reading the ns-3 codebase look at this and take
it as a model to emulate. Bad. Moving it to src/contrib is a way to
partly alleviate this problem. But it worries me anyway.

  - extensibility: if the feature really works only for the very narrow
set of scenarios needed for the original contributor, the usefulness of
merging for _other_ users is close to nil.

> The main issues I see are:
> 1) what is the long-term story for maintaining parsing-specific code?
> Will the equivalent of scenario-specific code such as is in there for
> mobility just grow and grow?  Or is there a way to factor that out and
> perhaps leave the core RPC API in the simulator and have
> scenario-specific parsing code outside of the distribution or in
> example files?

Removing the scenario-specific parts from the current rpc code would go
a long way towards making this code more useful to others so, that would
be great.
> 2) how do we deal with the new library dependencies that this
> introduces?  Is this a configurable compile-time option?  Do we fetch
> these like we do with pybindgen?

Using configurable compile-time options would seem to me to be a
necessary requirement. i.e., our download.py script could download a
local copy for us if it does not find them installed already on the
build system.


More information about the Ns-developers mailing list