Public SourceMage Discussion List

[Robert Figura <rfigura AT aubergine.zwischengesicht.de>]

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;}