[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Configuration frontend



Previously James LewisMoss wrote:
> Specifying that a configuration should be done in a postinst (or
> elsewhere) is a good thing.  This isn't the best.  You need to be able 
> to group everything together so that all questions are asked at once,
> and you need a more complex question setup than one script call should 
> reasonably give you.

Exactly.

> This is good, but it's got to be some separate data file describing
> what the questions are with front ends that parse that data file.

Indeed.

> <front end> asks questions and creates another data file/pipe
> describing status to set and passes it to <backend writer>.  There
> needs to be provisions for sections of the current status data that
> are not touched but instead passed back to the writer backend as near
> exactly as they were created (don't want to strip or mess with
> comments in the code.  That drives me nuts).

And here you go wrong. Everyone please remember what I'm going to say
now: what we are currently talking about is a tool that handles
installation of packages and the necessary interactivity that is
associated with that. We are NOT talking about configuration of a system
on general. To translate to the way-to-popular windows terms: we are
talking about doing something like installshield, not something like the
control-panel.

> Yup.  That's why the config file describing states has either got to
> be 1) a very complex config file

I'ld just *love* to be able to use a visual language like labview to do
this. Easy to use for maintainers, makes spotting logic errors simple,
no more syntax errors, etc. Unfortunately it's hard to implement. Maybe
one day when I have lots and lots of free time and absolutely nothing t
do..

> 2) able to be a separate binary of some sort that actually drives
> whatever frontend is there.  So best option is to have 3) either a
> fairly simple good in 90% of the cases config file or a binary that
> actually drives the front end (with some standard interface between
> the binary and the frontend).

I don't really see what you mean with 3, but I think it's what is
already in my proposal.

Wichert.

-- 
==============================================================================
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: wakkerma@cs.leidenuniv.nl
WWW: http://www.wi.leidenuniv.nl/~wichert/

Attachment: pgppCibsTjcIM.pgp
Description: PGP signature


Reply to: