Hi Emil,
I'm all for it. SEMS configuration is an area which has accumulated
some technological dept; so far for us it was always not urgent enough
to have us rewrite it.
Some things to consider inline
o Emil Kroymann on 11/11/2011 10:42 AM:
Hi,
we had some problems with our customer because of the complexity of
SEMS configuration. Therefore I have some ideas on how SEMS
configuration can be simplified.
I think the biggest part of the complexity comes from the fact that
configuration is split in several files. I think it would be easier
if all the configuration, for the core and for the apps would be
contained in one file with multiple sections. Also, from the
for simple/specific setups that would be preferable.
What I would also like, is to have something like apache
a2enmod/a2dismod, which just places links to application config in a
directory. If the link is there, the module is loaded and configured
with what is contained in the configuration file. This also makes it
possibly to install application packages without changes in the sems
package.
application authors point of view, it is hard to programatically access
the configuration of the core, and this leads to duplication in the
do you have an example of a core configuration parameter which you
need to access from an application?
configuration files.
Another part of the complexity stems from the fact, that errors are
detected too late. Errors like missing files, typos and inconsistencies
should be checked as soon as possible, at best, before the process is
daemonized. For the application author it should be made easy to
validate the loaded configuration.
definitely
The application we had the problem with, is a DSM application and
configuration for DSM applications is even more complex. It seems that
all of the configuration values present in the DSM dialog have to be
configured as extra keys in dsm.conf. This leads to complexity because
the application configuration and the configuration required by the dsm
module are mixed together in one big mess.
Maybe you have missed that specifically for DSM applications, there's
the separate application configs in conf_dir. This lets you nicely
separate out all configuration for one DSM application (scripts,
config variables, register_apps, system dsms, etc) in an extra config
file ('section'). The additional advantage is that you can package and
install DSM application as completely separate debian package without
the need to modify the sems package for it. Just install mydsmapp.conf
in the path set in conf_dir (/usr/local/etc/sems/dsm/) and voila.
My idea is to replace the configuration loading implemented in
different parts of SEMS by a singleton configuration manager
accessible in the core and in the applications, which loads
configuration from a single file, which contains multiple sections and
subsections. For validation of the configuration file, each key in the
configuration file has to be declared (registered with the
configuration manager instance) with a type specification in c++ code
either in the core or in the applications. The configuration subsystem
should provide means for most of the common required type
specifications and also be extensible by applications. For DSM
applications, declaring configuration keys and types should be
available as toplevel commands in the DSM script and the keys declared
in the script should be made available to the DSM script when it starts.
Declaring configuration keys could take the following syntax:
ConfigMananager::declare("core/listen/<listener>", "hostport",
"core_listener_hostport", IpHostPort(), "0.0.0.0:5060");
The first parameter is the section. The second parameter is the key
name, the fourth parameter is the name for accessing the configuration
value in the code, the fifth parameter is the type specification, the
last parameter is the default value. The section can contain
placeholders in angle brackets. When looking up the configuration keys
in the part of the code using the configuration value, replacements for
the placeholders have to be supplied. Also all values supplied for a
placeholder in the configuration file, can be looked up in the
configuration manager.
makes sense.
Something to possibly keep in mind (possibly such that it can be
implemented later):
It would make sense to have configuration manageable at run-time.
Therefore, the application might declare whether a configuration key
can be changed at run-time, and e.g. additionally pass a callback
which is called on configuration change.
My question now is: if I were to implement such a system in a branch,
would you be willing to integrate it into SEMS?
definitely, we happily accept all properly implemented improvements.
Thanks and Best Regards
Stefan
Regards,
Emil
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
