App Store Technical Requirements
- 1 Background
- 2 Links
- 3 Requirements
- 4 Enhancements
- 5 Project plan
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.
There are two main components:
2) back end The back end will be the bake build orchestration tool.
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.
The following is a possible three month project organization to deploy the app store.
Phase 1 (4 weeks)
- Obtain access to a virtual machine sandbox that contains a clone of the ns-3 Wordpress-enabled web server
- Integrate an app store instance with existing Wordpress installation
- Test that main features are functional by populating the app store with a few apps (in different categories). Some apps are likely to be enabled by ns-3.27 timeframe, so these can be used as a starting point.
- Provide URL link to the working instance to the ns-developers list and request community feedback
Phase 2 (4 weeks)
- Incorporate feedback from phase 1 review
- Enable techniques to leave comments or ratings of apps
- Integrate bake XML (bakeconf.xml) with the app store metadata
- Update ns-3 project documentation (tutorial, how to create and publish an app)
- Address any loose ends necessary to make the site live
Phase 3 (4 weeks)
- Work with mentor and module contributors to deploy as many apps as possible in the remaining timeframe (populate the app store).
- Doxygen and Sphinx documentation to be built separately per-module, but integrated on the main web site
- Support groupings and dependencies between apps by creating an 'ad hoc routing' group that a user can install
- Extend jenkins scripts to perform regression testing of all apps in the store