A CS Response (Re: The art of debconf)
Thank you for pointing out this issue, so that
I can insert some rant here. :) I personally think that the
issue goes as far as the basics of UI design. In UI
design one may view the problem as having two language
processors for translation of the interacting languages:
i) human -> computer
ii) computer -> human
Pragmatic vendors, such as microsoft, completely ignore
such basic issues, and the wizard phenomena has emerged
recently in "consumer grade" configuration tools. Although
the so said wizard approach can be traced back to a naive
work flow model, it may be easily shown to be inadequate and
inflexible for complex tasks. A scientific method to show
how implausible this "twiddling" or "patching" automatically
generated configuration "files" wold be to compare the cognitive
load and the maintenance effort of such customized configurations.
In the Debian distribution, a similar situation arises
in the case of software upgrades, and in special requirements
of users as John has referred to.
Of the two languages, the wizard approach would be
processing only the former and omit the latter. A familiar
obstacle presented by "wizard" interfaces is that it is
a "fire and forget" approach, and that it does not preserve
information, especially after the computer language has
been modified external to the "wizard". As an example
of the failure of "wizard" systems, I'd like to point out
to Windows NT networking installation wizard upon whose
failure the whole networking subsystem is rendered unusable.
A reminiscient case is the recent naive attempts at providing
GNU/Linux distributions with wizard-driven graphical installations.
Therefore, wizards are only a dumbed down class of UI
configuration tools which implement a simple work flow graph. :)
The details of the work flow are usually tool specific.
A more detailed work flow based design, however should
take into account various requirements and habits of user,
which includes personalizing configurations.
(I'm not going into an explanation of the above statements)
I would predict that one of the most important requirements
is persistence of customizations unless they are obsoleted
by software upgrades. In that case, the configuration tool
nicely removes that customization, (such as a feature
no longer being available), and warns the user.
The implementation of such persistence may be achieved by
an intermediate language, previosly referred to by John
as "templates" I presume. This would involve the following
translations.
human language ->int. computer language
int. computer language -> human language
int. computer language -> annotated computer language
annotated computer language -> int. computer language
The requirement for the target computer language is thus
an annotation syntax. Those software packages which do not support
arbitrary comments are ruled out, and should be revised
to support such syntax.
In this approach, the intermediate computer language, henceforth
referred to as Lic is a superset of the annotated computer
language (denoted as Lac) semantically. That is lossles translations
between two languages must be possible. The architecture implied by
this approach also removes any need for introducing user interface
components for the annotated computer language. In the architecture,
one would expect that all UI components are bound only to the
first two translations, and that the second couple of translations
are completely detached from any human interface whatsoever.
It is the UI programmer's responsibility to assure faithful
consistency between the first set of translations, while it
is task of language designer's responsibility to assure that
the subset property between Lic and Lac is possible.
If I remember correctly, Apple's MacOSX boasts XML as Lic
implementation. Neverthelesss, it is debatable whether XML
standard should be adopted for such tasks. (Caution: Does this
cause a bloated web browser/xml editor in our configuration tasks?)
In my opinion, there should be native UI tools for interacting
with Lic, making use of intuitive user interface elements for
representation of Lic semantics. As I reported earlier, the
user interface tools only interface with the Lic, the Lic may
also be used by other tools, be it automated or user invoked.
The Lac, apparently, is transparent to those tools, the conversion
is guaranteed to be completed upon a modification of Lic sentences.
Although the Lac seems suspect, I believe it should not be so.
However, it would cause some pains if the user wished to remove
annotations. In that case, I believe certain error recovery
strategies could be brought for consideration. For instance,
an aspect of the configuration tool involves versioning /
backup of configuration "files". The tool could detect offensive
or destructive changes and therefore failure to translate
configuration information, and ask for recovery of a previous
version, which could be seen before reverting. In my opinion,
a full history of configuration information should be kept.
It is also advisable that only monotonic adjustments are allowed
(upon a tool option) to Lac sentences, or that a subset of
Lac grammar is supported for annotated Lac phrases. Therefore,
a portion of Lac grammar may remain unsupported by Lic directly
and remain as an addendum to proper Lic syntax. That is, all options
that are not addressed by the configuration interface should still
be possible to add. If the Lac does not support proper annotations,
it should be improved to support it. On the other hand, there
is the problem of whether the whole endeavour for obtaining a
canonical configuration language is worthwile, since as John
suggested it may well be a waste of programmers' resources.
I would like to suggest that it need not be so, as long as there
are language tools which are preferably *not* written in an
incapable language as C, or a rather awkward language as Perl.
The grammar descriptions should be declarative, and should be
extensive enough to cover all possible Lac's, and be concise
and easy to develop.
That's all I had on my mind for the moment. Comments welcome,
--
++++-+++-+++-++-++-++--+---+----+----- --- -- - -
+ Eray "eXa" Ozkural . . . . . .
+ CS, Bilkent University, Ankara ^ . o . .
| mail: erayo@cs.bilkent.edu.tr . ^ . .
Reply to: