Ease of use and configurability

[Branden Robinson <branden@purdue.edu>]

Am I the only one who feels that, to a large extent, ease of use *is* a
technical problem?

This is a somewhat major proposal and would be a big piece of architecture
if implemented.  However it's something I've been kicking around in my head
for months and I haven't yet come up with a good counter-argument.

I'll also be pretty surprised if something similar hasn't been proposed
*somewhere* before.

I note that on April 20th, the "Gnome System Control Panel Project" was
announced (see http://www.gnome.org).  I think this is our opportunity to
work with its originator, Andy Doran, on making a consistent, easy, and
powerful interface for configuring programs.

My idea is this:

Every program that fetches user-modifiable files to control its behavior
(on a Debian system and according to the FHS, these should all be in /etc
or as dotfiles/dirs in $HOME) should have a kind an associated interface
file.  Call it /usr/lib/<package>/gconfig or something.

Now bear with me as I'm probably about to abuse some terms from both compiler
and object theory.

Most configration files are reducible to key/value pairs (sometimes a key
word may take multiple values simultaneously, as in a list of pathnames),
or a list of grouped key/value pairs (/etc/passwd).

To handle this we need to define some primitive object types, like
boolean
file
  directory (subtype of file)
  device (subtype of file)
  plainfile
  ... (you get the idea)
URI (Universal Resource Indicator, superset of URL's)
  URL (thus, URL is a subtype of URI)
integer
string

Maybe URI should be a subtype of string...that's a technical decision.  I'm
painting in broad strokes right now.

We must also allow the "interface" file to define its own object types.
For instance, /etc/password might do this; it is an aggregation of some of
the primitive data types mentioned above.

Some common methods should be written into the primitive objects (testing
for file not found in the file object, range checking in integer, illegal
character detection in string, etc.

We must also allow the "interface" file to override methods, and define new
ones of its own for existing objects and objects defined within that
interface file.

The bottom line:

For instance, an "interface" file for /etc/X11/xdm/config would work
something like this.  Be aware that I am no parsing guru and am in no way
wedded to the syntactical appearance of this; I'm just trying to
communicate the concept.

# interface file for /etc/X11/xdm/config

defineproperty(boolean(scaled,label("Scaled"),style("yes","no))
definemethod(readscaling,subtype(read)) {
  # read in line beginning with "catalogue"
  # for each of the comma-delimited filenames
  if (right(filename,9) = ":unscaled")
    fontpath.scaled = false
  else
    fontpath.scaled = true
}
definemethod(writescaling,subtype(write)) {
  if ! (fontpath.scaled) {
    fontpath.value = fontpath.value + ":unscaled"
  }
}

definetype(fontpath,subtype(directory),addproperty(scaled), \
 addmethod(readscaling),addmethod(writescaling))

boolean(clone-self,label("Clone self"),style("on","off"))
boolean(use-syslog,label("Use syslog"),style("on","off"))
setof(fontpath(catalogue,label("Catalogue"))
plainfile(error-file,label("Error file"))
integer(default-point-size,label("Default point size"))
setof(integer(default-resolutions,label("Default resolutions"))

Okay, hopefully some of you will be able to get the gist of what I mean by
all of the above.

The great thing about this approach is that you can build a data structure
understood by gconfig internally, then hand this off to a desired
front-end (dumb,ncurses/slang/newt,gtk).

Would this be hard as hell to implement?  Hell yeah, probably.  But think
of the potential rewards.  Once implemented, initially, package maintainers
would have to do the work of developing a thorough understanding of their
packages' config files.  But once this thing catches on, upstream
maintainers may begin to show an interest.

Pipe dream, or can we make it real?  Or does this suffer from some horrible
conceptual flaw that I haven't thought of?

I must also say that I am sure I do not have the coding expertise to
implement much of this at all.  If I did, I'd be on it.

-- 
G. Branden Robinson                 |  Never underestimate the power of human
Purdue University                   |  stupidity.
branden@purdue.edu                  |  -- Robert Heinlein
http://www.ecn.purdue.edu/~branden/ |

Attachment: pgpgUsLKta2nu.pgp
Description: PGP signature