So CFG won't interfere with any hand-editing or other means of config manipulation. The parsers know the syntax and the meta-config definitions are the source of the semantics. CFG itself saves configuration state only in the original config files. The top-layer then provides utilities and different methods for frontends to querry and access the whole representation. Here is the short version of how it works:ĬFG's middlelayer adds the configurations it reads from the various back-end's syntax parsers to a unified XML representation according to the meta-config definitions it finds. An end-users frontend could choose to render an icon view and only forms and wizards to alter configurations from the provided meta-data.
Don't get too caught up in the tree and key/value view.
In particular look for the usage of "forms". In addition to the info below you might want to read the CfgFAQ, and look at the screenshots of the GTK- client prototype. * Lossless config file updates/transformations * Help texts and comments from the config files along with the settings. * Different Interfaces (API, comand line, * Higher level meta-logic beyond "keys and values" (general Forms and Wizard logic available for frontends) The CFG framework features: * Simple access to all settings of a package Once a meta-config definition for an application is in place the whole CFG framework can be used on the referenced configuration. These files can be maintained and installed together with the applications themselves.
Its modular framework is based on config (file) descriptions for particular packages, called meta-config definition files. It can represent and modify hierarchies of settings in arbitrary config files/databases. General package maintainer script tasksĬFG is a three layered unifying configuration framework.
0 kommentar(er)
