Differences between revisions 3 and 4
Revision 3 as of 2004-09-13 11:23:04
Size: 2798
Editor: anonymous
Comment:
Revision 4 as of 2004-09-15 15:33:05
Size: 3821
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
 * Insert some nice scripting languages here  * 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...

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?

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.
Line 28: Line 53:
 * Multiple interfaces: 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...

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?
Line 47: Line 65:

== 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)

Debian Control Center Draft

User friendliness

  • 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)

  • 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...

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?

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

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)