App Store Technical Requirements - Revision history

Tomh: update app store requirements

2018-04-19T15:21:37Z

update app store requirements

← Older revision		Revision as of 15:21, 19 April 2018
Line 115:		Line 115:
	1. provide build scripts so that each module can be built, tested, and installed as a completely standalone library without invoking ns-3's Waf, although this will not be precluded if a user wishes to provide some build scripts to do so.		1. provide build scripts so that each module can be built, tested, and installed as a completely standalone library without invoking ns-3's Waf, although this will not be precluded if a user wishes to provide some build scripts to do so.

	2. provide build scripts to build the module Doxygen separately from the rest of ns-3.		2. provide build scripts to build the module Doxygen separately from the rest of ns-3 (perhaps this could be supported in ns-3.29 if someone can work on it).

	3. support modules that require patching of the mainline ns-3 release to function.		3. support modules that require patching of the mainline ns-3 release to function. We could experiment with including a <code>patches</code> directory that can store patches for the mainline that must be applied by bake.

	== Packaging ==		= Packaging for ns-3.29 release =

	The <code>ns-allinone-3.29</code> release tarball will contain all modules (the universe) supported for ns-3.29 and found in the app store. However, the default build of ns-3.29 will exclude the contributed modules.		The <code>ns-allinone-3.29</code> release tarball will contain all modules (the universe) supported for ns-3.29 and found in the app store. However, the default build of ns-3.29 will exclude the contributed modules.

			We may decide to later release subsets of the universe of modules (such as the so-called 'spins' of Linux desktop distros), but for simplicity's sake for ns-3.29, we will just include all.

			We may decide to migrate some relatively unused existing ns-3 modules from <code>src</code> to <code>contrib</code> at release time, to shrink the default build.

	Proposed API:		Proposed API:

	# will exclude contrib modules:		# by default, will exclude contrib modules:
	$ ./waf configure --enable-examples --enable-tests		$ ./waf configure --enable-examples --enable-tests
	# ~~will~~ include sample-module in the usual way:		# selectively include sample-module in the usual way:
	$ ./waf configure --enable-examples --enable-tests --enable-modules=core,network,lte,sample-module		$ ./waf configure --enable-examples --enable-tests --enable-modules=core,network,lte,sample-module
	# ~~Will~~ include all src and contrib modules meeting dependency requirements:		# include all src and contrib modules meeting dependency requirements:
	$ ./waf configure --enable-examples --enable-tests --enable-modules=all		$ ./waf configure --enable-examples --enable-tests --enable-modules=all

			= Development workflow for contrib modules =

			The usual way for people to work on a new feature has been to fork ns-3-dev and either edit existing modules or create new modules in <code>src</code>. This results in a parallel repository to ns-3-dev, completely stand-alone from ns-3-dev.

			In the new model, authors will create standalone module repositories and will need to place them within the contrib/ folder of ns-3 to work on them.

			Will [https://gist.github.com/gitaarik/8735255 Git submodules] be the preferred recommended way for people to set up a contrib development environment? Someone should investigate this or propose alternatives.

Tomh: /* Project plan */

2018-04-19T14:37:19Z

Project plan

@@ Line 70: / Line 70: @@
 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.
-= Project plan =
+= contrib module requirements for ns-3.29 =
-The following is a possible three month project organization to deploy the app store.
+== Goals ==
-== Phase 1 (4 weeks) ==
+. The source code layout of a module is the same as a module found in the <code>src</code> directory of ns-3:
-* Obtain access to a virtual machine sandbox that contains a clone of the ns-3 Wordpress-enabled web server
+  bindings doc examples helper model test wscript
-== Phase 2 (4 weeks) ==
+.  Additionally, the module must contain two version files.  <code>VERSION</code> is the version number of the module, and should be a conventional sequence-based identifier (such as '1.0.0') allowing users to easily interpret older and newer versions.  <code>NS3-VERSION</code> is a recommended or known-good version of ns-3 with which the module is compatible, and should just be a single line.
-* Incorporate feedback from phase 1 review
+  release <release tag number>
-== Phase 3 (4 weeks) ==
+or
-* Work with mentor and module contributors to deploy as many apps as possible in the remaining timeframe (populate the app store).
+  changeset <mercurial changeset hash>
-* 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
+Examples:
-* Extend jenkins scripts to perform regression testing of all apps in the store

Tomh: /* Integration with bake */

2018-04-19T13:48:31Z

Integration with bake

← Older revision		Revision as of 13:48, 19 April 2018
Line 38:		Line 38:
	== Integration with bake ==		== 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~~.		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.

	== User feedback and comments ==		== User feedback and comments ==

Tomh: /* Requirements */

2018-04-19T13:47:50Z

Requirements

← Older revision		Revision as of 13:47, 19 April 2018
Line 30:		Line 30:
	#. Clear documentation must be posted on how to use the app store, and how to submit a new app to the app store		#. 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 development directory, and then the ns-3 build tools (invoked at command line by users in the normal way) will do the rest.		#. 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 development directory, and then the ns-3 build tools (invoked at command line by users in the normal way) will do the rest.
			#. XML for the bake configuration will also be maintained for each module, allowing module contributors to post new releases of their module.

	= Enhancements =		= Enhancements =

Tomh: /* Requirements */

2018-04-19T13:46:51Z

Requirements

← Older revision		Revision as of 13:46, 19 April 2018
Line 24:		Line 24:

	= Requirements =		= Requirements =
			The following requirements were used to develop the app store (https://apps.nsnam.org).
	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.		#. 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.		#. Each "app" will be an ns-3 module, with a description page including: Description, screenshots (optional), 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		#. 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.		#. 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 development directory, and then the ns-3 build tools (invoked at command line by users in the normal way) will do the rest.

	= Enhancements =		= Enhancements =

Tomh: /* Background */

2018-04-19T13:45:06Z

Background

← Older revision		Revision as of 13:45, 19 April 2018
Line 5:		Line 5:
	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 [https://www.r-project.org/ R statistical framework] does not integrate every extension to its main release; instead, it allows users to [https://cran.cnr.berkeley.edu/web/packages/available_packages_by_date.html 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. [https://www.bioconductor.org/ bioinformatic packages]). We envision the same for ns-3.		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 [https://www.r-project.org/ R statistical framework] does not integrate every extension to its main release; instead, it allows users to [https://cran.cnr.berkeley.edu/web/packages/available_packages_by_date.html 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. [https://www.bioconductor.org/ 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.		In the ns-3.27 release, the bake build orchestration tool was extended to allow third party contributed code modules to be added to ns-3, and to be downloaded, built, and installed with the main ns-3 release. This allows modules to be hosted elsewhere and integrated with the ns-3-allinone framework. Consider this to be the back-end support for modularization. We have not gone further since that time.

	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 [[BakeIntegration \| on this wiki page]].		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 [[BakeIntegration \| on this wiki page]].
Line 11:		Line 11:
	There are two main components:		There are two main components:

	1) '''front end''' The ~~front end of this will be something like the [http~~://apps.~~cytoscape~~.org~~/ Cytoscape~~ app store~~]. A [[GSOC2017AppStore \| GSoC 2017 project]] is developing this~~.		1) '''front end''' The ns-3 app store (https://apps.nsnam.org) is largely operational and will be put into actual use for ns-3.29. The app store can be used to directly download contributed modules, and to post information about the module.

	2) '''back end''' The back end will be the [https://www.nsnam.org/docs/bake/tutorial/html/bake-over.html bake build orchestration tool].		2) '''back end''' The back end will be the [https://www.nsnam.org/docs/bake/tutorial/html/bake-over.html bake build orchestration tool].

Tomh: add workflows

2017-05-24T16:17:03Z

add workflows

← Older revision		Revision as of 16:17, 24 May 2017
Line 15:		Line 15:
	2) '''back end''' The back end will be the [https://www.nsnam.org/docs/bake/tutorial/html/bake-over.html bake build orchestration tool].		2) '''back end''' The back end will be the [https://www.nsnam.org/docs/bake/tutorial/html/bake-over.html bake build orchestration tool].

	= ~~Links~~ =		= Workflows =

	* [http:~~//wiki~~.~~cytoscape~~.~~org/AppStore Cytoscape wiki]~~		We envision three types of users:
	* [https:~~//github~~.~~com/cytoscape/appstore Cytoscape~~ app store ~~code repository]~~
	* [https:~~//github~~.~~com/cytoscape/appstore/wiki/Running-App-Store-on-Docker-Containers Cytoscape docker containers]~~		#. '''End user:''' The normal user will browse to the app store to learn about available apps, learn about resources (user forums, documentation) about each app, and possibly leave feedback on a review board. The normal user will obtain the necessary information to fetch and install each app from this page.
			#. '''Developer:''' Developers will not be able to create new apps on the app store, but will be able to edit the app page that he or she owns. To make an app available on the store, it has to go through an ns-3 review process.
			#. '''Maintainer:''' ns-3 maintainers will create a new page for an accepted app, and create a developer account for the author. Then the developer will be able to edit the page to suit their app.

	= Requirements =		= Requirements =

Tomh: /* Background */

2017-05-24T14:38:37Z

Background

← Older revision		Revision as of 14:38, 24 May 2017
Line 9:		Line 9:
	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 [[BakeIntegration \| on this wiki page]].		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 [[BakeIntegration \| 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 [http://apps.cytoscape.org/ 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~~.		There are two main components:

			1) '''front end''' The front end of this will be something like the [http://apps.cytoscape.org/ Cytoscape app store]. A [[GSOC2017AppStore \| GSoC 2017 project]] is developing this.

			2) '''back end''' The back end will be the [https://www.nsnam.org/docs/bake/tutorial/html/bake-over.html bake build orchestration tool].

	= Links =		= Links =

Tomh: project plan

2017-03-29T17:35:36Z

project plan

← Older revision		Revision as of 17:35, 29 March 2017
Line 63:		Line 63:

	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.		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.

			= Project plan =

			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

Tomh: update app store requirements

2017-03-29T17:00:48Z

update app store requirements

Show changes