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
application authors point of view, it is hard to programatically access
the configuration of the core, and this leads to duplication in the
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.
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.
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.
My question now is: if I were to implement such a system in a branch,
would you be willing to integrate it into SEMS?
Regards,
Emil
--
Emil Kroymann
VoIP Services Engineer
Email: [email protected]
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
signature.asc
Description: PGP signature
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
