The header is divided into two parts, an external and an internal one. The
actual splitting is done in a later commit and this commit only prepares
the header for the split.
Filters, monitors and routers can now declare parameters and those
parameters will always be present. Currently, this removes the need to
parse simple values like booleans and integers.
Some of the more common parameter types could be added in the future
e.g. paths to files.
The server weighting parameters couldn't be altered online and they
weren't serialized to disk. Only servers that are created online will have
their weighting parameters persisted to disk.
Router and filter instances cannot be destroyed before all worker
threads have exited. Otherwise there is a risk that data gets deleted
while someone might still be accessing it. Further, since all router
and filter instances are created by the main-thread it is better that
they are deleted by that thread as well (and not by whichever thread
happens to execute service_shutdown()). That will reduce the risk that
some unknown assumptions are violated.
The service header in include/maxscale/ contains the public part of the
service API. These functions can be safely used by the modules.
The internal header located in service/core/maxscale/ is used by the core
to initialize MaxScale at startup or to provide other services in a more
controlled way (the config_runtime, for example).
