Perils of Config Files (was DogCows or Polymorphism in the Hurd)

[Jonathan S. Shapiro]

Bas has proposed a design relying on external configuration files to
decide what "facet" is the default when an object is opened.
Specifically, he wrote:

> On Tue, 2006-02-07 at 10:24 +0100, Bas Wijnen wrote:
> > 
> > > I would consider a setting "open under name 's/(.*)\.tar\.gz/\1/'" in some
> > > config file of the graphical shell. 

And I responded:

> > Oh wonderful. 15 billion more things that won't get tested and make
> > customer support absolutely impossible because the support agent cannot
> > figure out what the hell the application is doing.

I can see from his reaction that I was excessively obscure.

The problem with Bas's proposal is that he hasn't carried it through to
its logical conclusion, and so he may not see that he has just invented
a 400 pound gorilla. I am going to ask some leading questions about this
proposal. As these questions are answered, the configuration language
will become increasingly complicated. Eventually, it will collapse of
its own weight.

Q1: For every configuration option, there will turn out to be some
program that needs to see the "real" story. How does an application
override the configuration environment? It should be able to do so on
one or two file types without doing so for all file types.

Q2: You will quickly find an example where one application needs to see
one default but another application needs to see another default.
Shouldn't the configuration file state configuration options in a
context-sensitive way?

Q3: In fact, you will find cases where the *same* application needs to
use different configurations in different contexts, in the same way that
two copies of xterm may need different configurations in .Xresources.
How does the language deal with this?

Q4: You will now discover that the "context of default" is not limited
to a single program. For example, when the shell invokes /bin/ls, it is
relying on /bin/ls to produce output in some particular format. This
means that a creating process needs to be able to narrow or eliminate
some of the user-specified options in order to get the expected result.
This implies in turn that all shells must know in advance all of the
configuration options that they may need to disable, or else that the
configuration mechanism needs to express things like:

  ls started from command line should behave one way
  ls forked internally by shell should behave a second way.

Note this problem is recursive. We must also consider

  ls started by foo ... started from command line

Q5: We now have a countably infinite space of options (indexing the
options now requires the omega-0 ordinals, which is the outer limit of
countable infinities). It is inevitable that no developer will
successfully consider all permutations. Indeed, it is inevitable that
there is no finite way to *express* all of the possible controls that a
shell might wish to impose on the behavior of sub-programs for scripting
purposes. How do we build test cases?


Q6: Isn't it much simpler to bind each filename to a single facet?


shap