modularity in gluon

handling of modularity and dependencies in gluon

TODO: This article now generally shows some basic ideas, but is factically not true for those examples chosen here. See end of article. Maybe replace respondd with statuspage in example

The gluon framework tries to be as modular as possible. So there is a set of some core packages which can be extended with additional features. As a developer you might be in the situation to decide in which packet your code should be located.

Core concepts are:

• packages: Packages are the smallest unit of functionality. Packages are collections of files, packaged into *.ipkg files and are unpacked via the opkg package manager. They can be directly built into the firmware or installed afterwards live on the router (while this way is not used very often in gluon).
• features: Features are more abstract descriptions of functionalities. Features may include multiple packages and are an abstraction for the gluon user which do not want to harm with the internal package dependencies. When building a firmware the user just has to specify which features (statuspage, respondd, ...) it's firmware should have.

Some examples of situations which you might have to solve when adding code to gluon:

• Beginning: You want to write some code which acts as a data provider for respondd (the statistics daemon).
  • Situation A: The respondd provider should provide data from core packages, which are not an optional extension. So theoretically the provider could be located in the gluon-core package. But since the statistics daemon is an optional feature, the new provider should not be included when respondd is not included. So putting the provider into the gluon-core package seems not to be to be a really good idea. But for now let's first consider Situation B, before we come back here.
  • Situation B: The respondd provider should provide data from a babel package. Babel itself is one of the features, which are optional. So we want our provider to be built into the firmware if (and only if) both babel and respondd are selected features. This is solved in gluon by creating a new package for the provider (e.g. gluon-mesh-babel-respondd). As this leads to a lot of packages with logical connections and dependencies, it's often really hard for the gluon users to keep track of all those packages. Since 2017.2+ there is a mechanism called features which automatically handles those type of dependencies, so the packet gluon-mesh-babel-respondd gets automatically selected when the features babel and respondd are selected. The user no longer has to know about the internal packet structures.
  • Back to Situation A: Using features we could now create a package gluon-core-respondd. But this does not really makes sense, since the gluon-respondd feature already has a hard dependency on gluon-core (just as nearly all packages are depending on gluon-core). The stupid easy solution to this problem is, to put the respondd provider for stuff in gluon-core into the gluon-respondd package. The hard dependency to gluon-core makes this possible.
• Another example is statuspage for the statuspage backends for batman and babel.

While writing this article, I just noticed, that in this special case (of batman and batman) it's not handled that strictly yet. The gluon-mesh-batman-adv depends respondd and so the respondd providers for gluon-mesh-batman-adv do not be external.