App Store Technical Requirements
The goal is to support modularization of the ns-3 code base and federation of development activities. To date, the main path to distributing extensions to ns-3 has been to request a code review for merge to the mainline tree. The future goal is to shrink the ns-3 core, and to better facilitate modules that are independently developed and maintained. As a concrete example, the R statistical framework does not integrate every extension to its main release; instead, it allows users to fetch the packages of interest and add to their installation. Communities-of-interest have even arisen to allow researchers to organize and curate sets of R extensions (e.g. bioinformatic packages). We envision the same for ns-3.
We are taking steps, to be first enabled for ns-3.27, to allow third party contributed code modules to be added to ns-3, and to be downloaded, built, and installed by ns-3's bake package management tool. This will allow modules to be hosted elsewhere and integrated with the ns-3-allinone framework. Consider this to be the back-end support for modularization.
For example, the sift routing code contribution has been added as a module. Please review how users are expected to add sift to their ns-3.27 release on this wiki page.
What we seek in an app store is the web-based front end that allows users to discover packages. It turns out that another open source project (Cytoscape) has already built such an app store that is basically what we seek; see the Cytoscape app store. Moreover, the code to deploy this app store is open source, and is designed to work with Wordpress, meaning that we could, in principle, deploy an ns-3-centric instance of this.
The main functional goal is to deploy something very close to the Cytoscape app store on the ns-3 web server. However, because ns-3 does source and not binary distributions, this tool will facilitate source code downloads of modules (apps).
- . The front page should be clean, consisting of categories, newest releases, and popular downloads.
- . Each "app" will be an ns-3 module, with a description page similar to Cytoscape's page: Description, screenshots, download tab, resources tab, etc.
- . Clear documentation must be posted on how to use the app store, and how to submit a new app to the app store
- . The "Download" tab will fetch a source archive, and the user will download to a location of their choice. The user is responsible for moving or copying the package to their ns-3 build location, and then the ns-3 build tools (invoked at command line by users in the normal way) will do the rest.
Once the basic capability is deployed, enhancements are possible. Some of these extensions may involve modifying the app store installation, but some will involve modifying ns-3 build scripts, documentation, and other scripts (e.g. Jenkins scripts).
Integration with bake
Bake uses XML to describe modules. It would be nice to have a standardized XML schema that describes an ns-3 module, and make it usable from both the app store and from bake. For instance, there could be an "authors" field in the XML description that can be displayed by bake at the command line and can also be parsed and shown as the Authors in the app store description. A Wordpress plugin might be able to accomplish this.
User feedback and comments
We probably want to explore and tailor the capability for users to provide feedback and hints about apps. We do not want the capability to be abused by spammers (e.g. a captcha?).
Documentation and module creation scripts
- Doxygen and Sphinx scripts should be modified to allow building on a per-module basis; ns-3 web site should still integrate all of these module documentations coherently
- The create-module.py program should be updated
- The ns-3 tutorial must be updated
We need to write some new Jenkins scripts to test the known modules for regressions.
Managing the version numbers of different apps will be necessary. We want users to be able to declare that apps are compatible with specific ns-3 versions.
Apps may fall out of date (become unmaintained) but it may be the case that some simple patches could be applied on top of them to make them workable again with the latest ns-3. The framework should support the ability to declare that a module installation consists of downloading an archive and then patching it with a file fetched from elsewhere. A module may also require patching of ns-3 core itself; the framework should support this.
If some modules depend on other modules or system dependencies, that needs to be expressed and handled by the tools. This is mainly a bake build issue, but it probably requires also some documentation in the app store that the module depends, for example, on a system library such as Boost.
We will probably want support for groups of modules. Users should be able to specify, for example, "Ad hoc routing" and fetch modules for several protocols, which may be hosted at different sites.