[Config4gnu-developer] Re: [rox-devel] menu-click configure an App

[<p.c...@ar...>]

Thomas Leonard wrote:
> On Wed, Jan 07, 2004 at 12:41:14AM +0100, p.c...@ar... wrote:
> > 
> > Hello! 
> > Would anybody like to have a "Configure" menu entry for appropriate apps
> > and like to hack on config4gnu for that?
> > 
> > Config4gnu (or CFG for short) takes a meta-config-definition file for an
> > app and can then be used with generic fronteds (command line, GUI, etc.)
> > to configure every option of that app.
> 
> We already have a similar system (Options.xml) which describes the GUI for
> the options. What is the advantage to using C4G for this?

Amazing, no matter how sweet the candy one wants, rox has already got it! ;-)

(Looking through the wiki I also liked AppDirs, see my other post)

Seriously though, nice Options!

I will try to provide a rough comparison to CFG:

As CFGs primarily focus is on configuring arbitrary system settings or services it offers support for different config file formats. In a CFG XML meta-config-definition file (analogous to Options.xml) there is also a file format specified. For example "INI-style" for smb.conf (samba fileserver). CFGs meta-config-definition files do not primarily define the GUI but the config file semantics and which syntax parser to use.

If used in applications like the rox-options the analogous to rox.setup_app_options() in CFG would, in this example, accesses the settings in /etc/smb.conf.

To general configuration tool frondends all config files known by CFG are presented on a per option grained level in an XML-tree no matter what format the file has and where it resides. Each option with possible values, defaults, comments and optionally additional info from man pages etc. Multipurpose Frondends are basically only XML editors that comunicate with CFGs middlelayer. See the screenshots:
http://config4gnu.sourceforge.net/screenshots
A speciality are forms and wizards that can be defined in meta-config-definitons to describe a generic GUI or wizards to create new configuration entities like for example new samba shares.

-Peter




CFG Project Goals
-------------

- Provide multiple interfaces (command line, web-based, GUI, LDAP, etc.) that allow users/admins to modify configuration, with relevant documentation (man pages, etc.) integrated into the interface.

- Allow developers to easily create configuration interfaces for their software which will be automatically recognized by our system when the software is installed.

- Standardize the different types of configuration files (INI-style, flat/delimited text, Apache-style, etc.) and provide parsers and unparsers for all styles.

- Include ways for different OS's and distributions to tailor the system to their needs.

- Retain the native human-editable config files in /etc as the authoritative copy of system configuration and avoid mangling comments and indentation.

- Create a system which is general enough to allow a high level of flexibility but also specialized enough so that the specific task of configuration can be done efficiently.



Advantages of the CFG Project
-----------------------

 Everyone knows there are many other configuration tools for Linux, the most popular of which are Webmin and Linuxconf. Each distribution also often creates their own config tools, and many software projects provide config tools (SWAT for Samba, etc.). This results in duplicated work and inconsistent, buggy interfaces that constantly need to be re-written. 


The CFG Project changes this. Our system is based a three-tier approach with a powerful and flexible middle layer that handles the details and joins the backends which parse and unparse the config files with the frontends which provide various ways for users to edit their configuration. All this is done using XML to exchange data and the behavior is controlled by special meta-configuration files which determine how the middle layer behaves for each specific configuration task. 


That means in order to alter or extend our system, you simply add a new or updated meta-configuration file and the system recognizes it automatically without having to recompile or re-write any parts of the layers themselves. In that sense, software developers may think of our system as a type of sophisticated API they can use to configure their software. We plan to create tools to make it easy for developers to write meta-configuration files for existing software. 


End users never need to worry about all of this, since we hope software projects and distributions will take some or all of the responsibility for maintaining the meta-configuration files once the initial versions have been created by us. Users will only see a single consistent interface using their choice of frontends, while still being able to edit the config files by hand at times.