On Thu, Jul 30, 1998 at 04:08:59PM -0700, Joey Hess wrote:
> Antti-Juhani Kaijanaho wrote:
>
> I don't understand the meaning of "decisions" you are using.
I'm talking about the decisions over what actually gets asked.
Unfortunately no RFC describes a protocol for transferring thoughts
from one's head to somebody else's head. If you were here or I were
there I would take a pen and a paper and draw it, but that is not
meant to be.
Okay, I'll try to draw the picture with words. The current
configuration system has essentially only one UI. The user is asked
certain questions in certain order determined by the config script
based on the user's earlier answer. One of my goals here has been
making it possible to have several UIs that are radically different
from one another. The disadvantage of having a script control the
questions is that the following features are config-script-dependent:
* a user may want to reconsider her previous choices, so
we need to be able to go back to previous systems
* it should be feasible to build a configure frontend that shows
all the questions at the same time, thus allowing the user to
see what consequences her decisions have on what decisions
she can make in the future
If we just describe the questions, and let the frontend control the
presentation of questions, implementing those ideas do not require
anything special from the package config.
Does this help at all?
> > [my illustrative language]
> > > How is this different from:
> > [a shell script]
> >
> > They do different things.
>
> They both instruct the frontend to present the same tree of questions to the
> user.
Yes, that's their basic functionality. But they do it in
fundamentally different ways. The shell script literally asks the
questions (it uses the frontend as a I/O library). My way just tells
the frontend what questions are to be asked, and what sets of
questions and answers are consistent.
> Ok, here is the one huge, gaping, fatal hole in your poposal. Many config
> scripts in debian look at the current status of the system, and ask
> questions based on that. For example, lilo looks to see if the user has
> edited /etc/lilo.conf. If so, it asks one set of questions, otherwise, it
> does more probing to find out what is the name of the main linux partition
> on the system and presents that in another set of questions.
You just found the first genuine bug in my idea. Congratulations. It
is not fatal, however. Here is one way of fixing it. If you need to
have one set of questions or another set if questions, based on the
current status of the system (and not on the user's answers to other
questions), you can probe this in a script that is run before the data
is sent to the configuration frontend. The script then sends one set
of data if the probe returned foo, and another set of data if the
probe returned bar.
Antti-Juhani
--
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> ** <URL:http://www.iki.fi/gaia/> **
I can't seem to find a lowercase 'r' on my keyboard.
(Lee Davies in comp.unix.programmer on July 22, 1998)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
