Differences between revisions 4 and 5
Revision 4 as of 2004-09-15 15:33:05
Size: 3821
Editor: anonymous
Comment:
Revision 5 as of 2004-09-27 19:41:15
Size: 4591
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
(Is it possible to get wiki page change notifications?)
Line 4: Line 6:
 * DCC should provide te 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)  * 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)
Line 36: Line 38:
{{{
 * Did you look at the CFG frontends? The gtk and html (php) frontend prototypes generate their ["UIs"] upon info from the middlelayer. (Refer to the fd.o link mentioned below)
}}}
Line 45: Line 50:
{{{
 * The config4gnu-wbem branch parsers/providers is in itself only a striped down version that completely ignores the three-layered design of the original config4gnu branch. We should prefer the three layered version! Maybe use d-bus on __top__ the middlelayer. 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?
}}}
Line 47: Line 55:

Line 52: Line 62:
{{{
 * Simply ssh to remote computers to access meta-config-definitions and config files there?
}}}

(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 CFG frontends? 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 parsers/providers is in itself only a striped down version that completely ignores the three-layered design of the original config4gnu branch. We should prefer the three layered version! Maybe use d-bus on __top__ the middlelayer. 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 as 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)