[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: System Configure tool
From:       Markus Kohls <markusk () bnet-ibb ! de>
Date:       2001-05-05 23:39:17
[Download RAW message or body]

Am Saturday 05 May 2001 22:20 schrieb Holger Schurig:
> > cvs checkout kdeadmin.
> >
> > Have a look into that module. Mostly unmaintained and unuseable.
> So there is already an interface between some GUI and some worker
> class. This layer would be a good point to have remote administration
> possible.
>
> Third, because of the huge amount of configurable things in a linux box
> I'm wondering how this can should be solved. kuser, kcron etc all
> solved this by hard coding everything in C++. That's a tedious task. I
> mused some time ago if it would be possible to create a "configuration
> file description language", augmented by actions and information gather
> methods. Those three parts would then be used for a central GUI to
> display the control on the screen (from the config file description
> language and info gather scripts) and for doing actions (by virtue of
> the action scripts). This file could, in the sourcecode, sent throught
> a preprecessor to make it distro-dependent.
>

I had the same idea with a friend of me some months ago, and we also thought 
of an kde-integration. But nobody really had time and fun to finally write 
any sourcecode (only some tries with some xml files, xslt scripts, and 
Xalan+Xerces). Take a look at http://gxconfig.sourceforge.net for this old 
project.

Perhaps i can tell you, what ideas we had at that time. The Central 
Configuration should be saved in a XML-File, where the abstract Configuration 
Data should be stored. By including an xml-namespace you easily also can 
abstract the Interface of the Configuration Dialog (some kind of 
Configuration-Logic-Language). That means, if you have f.e. a option, which 
requires a radio button, you would simply save this information within the 
configuration-xml-file in the "xmlconf"-namespace.

This xml-file could be translated into one or several configuration files for 
the servers (if they can't read the xml-config-file for themselves) with the 
help of xslt. With it, you also could generate a interface, but i'm sure, 
this is not a practical solution (converting f.e. a xml-config-file to 
qt-xml-ui).

The advantage of abstracted ui is, that you could not only configure your 
local server, but also administrate servers via web. You even could make a 
win2000-frontend administrating a sendmail server, or a linux-console 
configuring a microsoft exchange server.

Another idea was to store the information in the xml-file not dependant on 
the name of the server (sendmail, exim) , but on the tasks it should 
accomplished. You could then include some entities which contain some global 
information (which operating system, distribution etc.) and the xslt script 
should be able to convert the xml-file for different mail-servers. (at least 
if they are not too different). You could avoid some differences in some 
configuration files between the different unix-variants there.

Hope this helps a bit, excuse me for bad english. :)

cya. markus

-- 
Markus Kohls - Postmaster http://www.bnet-ibb.de

eMail: markusk@bnet-ibb.de
PGP key: http://www.mvm-consulting.de/~markus/gpgkey.txt
home: http://www.gestoert.de

[prev in list] [next in list] [prev in thread] [next in thread]