Re: Configuration management, revision 3
On Wed, 29 Jul 1998, Joey Hess wrote:
> Why don't we then just send the frontend a lump of shell code and use that
> as our implementation language? The only reason I see why not is that then
> the frontend would have to parse the shell code. Well, then, why not make
> there be an interface between the shell code and the frontend (like the one
> originally proposed, say) and the frontend just pasres that? Ok, if there's
> an interface we can move the shell code out of the frontend and into the
> backend, and we're back to the original proposal.
Okay, let me try to explain how I see this.. There are two ways to produce
the same effect to the user, both require the packager to provide code to
perform the configuration and both effectively allow a wide sophistication
for what is configured.
In truth either would do to solve the immediate problem, but there is one
important distinction and that is how configuration information
construction is controlled. Wichert's proposal is basically
this:
- Configuration is controlled by a script. Each package has a script and
they are run sequentially before installation begins.
The other side of the coin is:
- Configuration is controlled by a generic database browser. The user
has the option of running per-package scripts before configuration.
I think of the difference alot like 'push' vs 'pull', Wicherts proposal
PULLS the information from the user mine PUSHES the information to the
package.
The distinction doesn't have make much difference when you look at a
single package, who cares if it pulls or pushes, it does it's query thing
and then it's done - either way it works.
Look at it from a broader perspecive, how will a Pre-Configuration GUI
look for N packages, what options will the user have, how will they
interact with it? Do you envision a simple series of prompts or as some
sort of exploritory tool allowing browsing of the value tree with some
'wizard' like things to perform complex configuration.
Jason
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: