(Is it possible to get wiki page change notifications?)
Debian Control Center Draft
User friendliness
DCC should provide the user with a central location for system configuration, this compromises both the users personal options and system wide defaults (or things that can only be configured for the system). The .desktop format described at freedesktop.org can be used to create a nice folder with links to all configuration tools. (Both kde & gnome support it)
- The user should not be confronted with configuration files. DCC applications should leave comments and formatting intact.
- User friendliness is the primary goal. Basic configuration is most important, advanced features can be (in a first stage) left unimplemented and should, if implemented, not be the first thing the user is confronted with (last tab/Expert button/...)
- At regular times: put your father/mom/grandfather/grandmother/... in front of your computer and ask them to configure something. Sit back (relax?) and look at how the average user responds
About coding it
Some things you should allready know
- The world is not expecting the next ugly cludge of code. Code should be organized in small modules, contain enough comments ... Some basic things most people expect of decent code.
- Only use C(++) code when a) you're working on existing code that's the best out there b) no other option is available (feels assembler jokes coming..)
- reuse
- Python, Ruby and Perl have been proposed as scripting languages.
User Interface
A layered model should be used to be able to provide multiple interfaces to the same piece of configuration software.
- Layer 1:
Different GUI libraries that interface with gtk/html/...
- Layer 2:
Mid-level componentized python scripts. Communicates with layer 1 through a uniform protocol common to all UI's.
- Layer 3:
Parsers for the low-level raw config files.
How accomplish multiple interfaces using the same code? You could write Yet Another Library for doing this... Haven't seen things that do html/gtk/qt/console...
Did you look at the real CFG frontends (not the wbem stuff)? The gtk and html (php) frontend prototypes generate their ?UIs upon info from the middlelayer. (Refer to the fd.o link mentioned below)
Debconf would probably be able to do it, but is rather limited towards user interfaces (no placement/limited number of widgets/no true interaction...).
Something you can't do with debconf: user has one main box containing 3 choises, based on the choise the data presented below that box changes and presents options specific to the choice made by the user
Should we extend debconf, or keep looking for something else for ui abstraction?
Configuration Files
The CFG project allready has quite some parsers for common configuration formats. Question is how we will interface with these parsers. Should we use WBEM, or should we instead rip the parsers out of CFG and define our own interfaces?
The config4gnu-wbem branch's parsers/providers are in itself only stripped down/butchered versions. It throws the three-layered design of the real config4gnu branch overboard. We should lend from the three layered version! Exept possibly use d-bus or something other than XML on top of the middlelayer. The config4gnu-wbem fork and short circuiting of WBEM into the parsers was only done because of a personal preference for WBEM and lack of time to implement WBEM correctly as another top-layer protocol interface. In case the combination of CFG's middleayer and their perl parsers makes any trouble would it make sense to rewrite the middlelayer in a scripting language?
Another option is using some lexing/parsing libraries available for python. With these parsing should be an easy process that can be quickly debugged and modified. Only thing we have to do is define our own interface.
/dev/random
Some random thoughts, eg. "this would be nice if..."
Network transparancy, eg. configure other computers localy - there are several ways of doing this, you could have the remote computer run something webmin-like or you could use the local applications to connect through < insert protocol > to a remote computer
* Simply ssh to remote computers to access meta-config-definitions and config files there?
What exists
A list of some applications/libraries/protocols that should be considered for inclusion/integration/usage
- Debconf
- Yast
- gnome control center
- webmin
- Configlets
http://freedesktop.org/Software/CFG (Use the config4gnu branch (not config4gnu-wbem) as a base for the backend and craft a really fine DCC frontend (see prototype screenshots))
- ...
- Not complete...
The gaps
Insert here the gaps that exist when configuring a debian system (eg. what we don't have tools for)
- Apache
- Runlevels (rcX.d)