Re: sysinst split project - The Configuration File

[Silas Silva <silasdb%gmail.com@localhost>]

On Wed, Dec 16, 2009 at 03:12:07PM +0000, David Holland wrote:
> It seems to me that there are at least three different questions here.

David, you expressed precisely what is the problem here. Splitting the
problem in different questions will be necessary if before sysinst
splitting succesfully ;-)

> One is: whether canned answers to canned questions (like "which
> password cipher?" or "what IP address do I use?") should be expressed
> as static data or as script hooks.

A choice will have to be made. What are the pros and cons of having
either scriptable or static configuration? Many people agree that it
should be scriptable and some prefer that it should be static (here I'd
put XML addicts).

If people decide that it should be scriptable, what will be used?  Lua,
Perl, Python, etc. or some new install lang that will be implemented?

> The second is: whether it should be possible to direct the overall
> progress of the install process using a user-supplied script, which
> e.g. plugs together components of sysinst and executes them.

I think I didn't got it right (mainly because of my poor English
understatement :-[), but what you mean here? That people will call
sysinst functions (components?) to achieve something?

If Lua was used, the configuration file could be expressed as a set of
tables, much like static data. The advantage of this approach is that,
before (or in the middle, or after) tables definition, people can call
anything in lua. Something like the e-mail from Alexander Nasonov in
this thread:

config {
    disk1 {
        disklabel {
            ...
        }
    }
}

For someone that doesn't know (and don't want to learn), it looks like
static data. For the ones who want to tweak the configuration file, it
can be expressed as a Lua program that produces tables that will be used
for sysinst. Just an idea, of course a totally different approach can be
taken.

> The third is: whether pieces of sysinst itself should be written as
> scripts, and if so, whether part of the available configuration
> process should involve editing those scripts.

I think that depends on whether or not a script language will be adopted
in base. If true, I see no problem implementing a big part of sysinst
(and not only sysinst.conf) in this language. If false, it turns more
difficult for having even only a scriptable configuration file (unless
we use sh, awk, etc.).

> It also seems to me though that directing the overall progress of the
> install is useful and perhaps important, and that should be done in a
> script language. Striking the right balance between this and requiring
> the user to edit complex scripts that ought to be internal to sysinst
> will take some thought.

What I've written about Lua tables above may help on this discussion. To
sum up: sysinst.conf may look either static or not.

>  > Couldn't sysinst import/export from/to both formats, human-readable (Lua
>  > script or another) and XML? That would solve the controversy, but it may
>  > be difficult to maintain support for two different standards.
> 
> Trying to transform scripts into XML is a bad idea.

Yeah... since the scriptable configuration approach is taken, it gets
difficult to convert things to XML :-/

-- 
Silas Silva