Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] [Fwd: Re: minimize global effects in CONFIGURE and DEPENDS (Was: Using dialog for the net-conf spell)]

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Robert Figura <rfigura AT aubergine.zwischengesicht.de>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] [Fwd: Re: minimize global effects in CONFIGURE and DEPENDS (Was: Using dialog for the net-conf spell)]
  • Date: Fri, 21 Apr 2006 18:37:06 +0200

On Sunday 16 April 2006 23:12 wrote Juuso Alasuutari:

> I'm glad I've understood some of the issues here. So, do you have any
> suggestions how we could further the goal and prepare the ground? As I
> said, I feel a roadmap would be good. (Keeping in mind of course the
> priorities of things with such a small crew that we have.)

I think it would be especially handy to have a clean configuration
dataformat. Gui configuration tools would then become a lot easier to
realize (or feasible at all). Saving and even mergeing of configurations
would relatively simple to implement. Should be quite useful in cauldron
and prometheus as well.

To ponder ahead: Will The dependency code of Sorcery play nicely? One way we
have the case where the gui config tool results indicate that a spell has
to be casted or removed. The other way is Sorcery signalling an additional
spell's config to be added.

The meat:

- Currently CONFIGURE computes what questions to ask and then asks.
Depending on the answers, different subtrees of the configuration
become relevant. This is hierarchical!
- Let's try to separate the code which finds out what config is relevant
from the tree representing all possible configurations.
- Sometimes questions will be implicitly answered based on scripted inquiry.
- Thinking a bit deeper it may be useful to think of the DEPENDS as being
related to CONFIG in this context.

I'll address these issues:

1. A hierarchical and script-free configuration format.
2. A set of external agents which may decide to make certain subtrees
irrelevant before asking questions.
3. Interface to Sorcery and dependency code.

I don't know if 2. is relevant. At least it is nice.


On one hand a line based config format has some advantages.
- Easy to parse
- Attracts hack-alike shortcuts i.e. may be bash-parseable

But i'd like to focus on the fields first therefor i offer an example config
file format like this:

[VARNAME]
# comment
field_name=value_name
...
[VARNAME2]
...

where fields may be:

# all nodes:
REQUIRE="VARNAME=value" # this node is relevant if VARNAME=value
TITLE="question to ask"
HELP="if needed"
DEFAULT="value"

# one type per node:
TYPE="YESNO"
R[0]="--configure-option-no"
R[1]="--configure-option-yes"

TYPE="CHOICE"
T[0]="option number one"
R[0]="--configure-option-one"
T[1]="option number two"
R[1]="--configure-option-two"

TYPE="PROVIDER"
WHAT="GLUT" # for example
# could be merged with AGENT:

TYPE="AGENT"
COMMAND="ls spec/config.spec" # let pwd be SPELL_DIR
# commands are executed as soon as they become relevant
# they write a list of options to stdout or a single one if no choice is
# possible


Some common sense additions: Definitions should be strictly free of forward
references. Similar Conditions should be grouped. It should not reference
any sorcery internals from COMMAND.

Answering the questions should result in the same 'protocol' for BUILD (and
friends) as we have it now:

VAR_NAME="value"


Now the hard part: How to integrate into sorcery.

First we need a way to communicate the answers back to sorcery. This could
be done by piping a simplified CONFIGURE (only simple assignments). Or by
generating proper tablet entries (doesn't feel right, though).

Also we need to address the dependency issue: As noted before dependencies
are similar to configuration. If we do not merge these two we'd need to
have communication between sorcery and the gui:

gui says: added/removed an optional_depend
sorcery answers: add/remove these sub-depends...

(I think this idea was already stated in this thread near the client/server
buzzword. Maybe a request executes sorcery^wgaze and the reply comes on
stdout - as simple as that)

If we merge we have all the nice code in sorcery to compute dependencies to
be reviewed or implemented again in the gui. May be faster though.


Now i see a slight redundancy since BUILD has sometimes to restate the
hierarchy in order to make sense of the configuration:

if [ "$VAR_NAME" = "y" ]
use "$VAR_NAME_SUB1"
else
use "$VAR_NAME_SUB2"
fi

Would be nice to have this automated as well but this is not worse than it
is now. Don't think that's very easy without severely disturbing the
current spell format. Probably this doesn't matter at all and i'm
hallucinating.


I'm not 100% sure about how many of the spells do sophisticated stuff in
CONFIGURE and if there might be cases which are impossible to convert.


Many details missing, no code yet. Comments Welcome.


Regards
- Robert Figura

--
/* mandlsig.c v0.23 (c) by Robert Figura */
I=1702;float O,o,i;main(l){for(;I--;putchar("oO .,\nm>cot.bitamea\
@urigrf <raguFit erobR"[I%74?I>837&874>I?I^833:l%5:5]))for(O=o=l=
0;O*O+o*o<(16^l++);o=2*O*o+I/74/11.-1,O=i)i=O*O-o*o+I%74*.04-2.2;}




Archive powered by MHonArc 2.6.24.

Top of Page