[Ns-developers] Cooperative ns-3 simulation with third party software via JSON-RPC
tomh at tomh.org
Tue Jan 20 10:46:28 PST 2009
>From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
>Sent: Tuesday, January 20, 2009 04:59 AM
>To: 'Sébastien Vincent'
>Cc: ns-developers at ISI.EDU
>Subject: Re: [Ns-developers] Cooperative ns-3 simulation with third party software via JSON-RPC
>To summarize, I see very little added benefit in merging this code and a
>lot of downsides. I would much rather point users who wish to
>inter-operate with ns-3 to XML-RPC than this very partial, complex, and
>hard to maintain solution.
I basically agree with the detailed (coding style, possibly misleading name for UpdateAgent class) comments from Mathieu, which should be fixable, but wanted to comment on the bigger question here (whether or how to merge).
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
To me, whether it could be done better with XML-RPC, in theory, shouldn't be a criteria for deciding on merging this one, unless someone is going to step up now and volunteer to write/document and maintain the more general XML-RPC variant. I do see a strong use case for this functionality, and perhaps others will, in time, work on XML-RPC variants too.
We have three primary paths for code contribution:
1) we accept into the main tree
2) we have a src/contrib directory for things that the maintainers are not yet sure is useful, or is experimental, or may have a long-term maintenance question, or possibly overlaps with an equivalent maintained model
3) ns-3 maintains pointer to a third-party website or repository, and it is maintained (or not) out-of-tree
If there is a reasonable path for resolving the more detailed issues Mathieu raised, and it does not create a build system maintenance headache, and someone is willing to maintain it, I'd still be in favor of exploring whether and how to merge it (to either src/contrib or main tree).
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?
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?
More information about the Ns-developers