Public SourceMage Discussion List

[seth AT swoolley.homeip.net]

On Fri, Apr 21, 2006 at 06:37:06PM +0200, Robert Figura wrote:
> 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.
> 

Clean means fewer features.  Right now it is turing-complete and with 
rich interfaces into the system.  The magical part of this distro is the 
scriptable configuration format

> 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.

This is unfeasable, for we lose power.  My suggestion, which is to 
require no global side-effects except on the last run doesn't limit 
its power.

> 2. A set of external agents which may decide to make certain subtrees
>    irrelevant before asking questions.

My suggestion accomplishes this, and all it takes is a re-parse of the 
script.

> 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

None of the suggestions below are backwards compatible.  Furthermore, 
they could be gotten out of my relatively compatible proposal.  I might 
need to fix fifty spells under my proposal.  You're proposing we rewrite 
them all for no actual benefit and many losses.

> 
> 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.

This command variable isn't magical to me.

> 
> 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.

My proposal required no integration into sorcery.  Sorcery stays the way 
it is.  We want less code in sorcery, not more.

> 
> First we need a way to communicate the answers back to sorcery. This could 
> be done by piping a simplified CONFIGURE (only simple assignments). 

You've broken most of its power.

> 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:
> 

I'd like you to take a look at the sorcery code that handles dependency 
resolution and see if you think it's feasable to have every gui 
implement it, including all the sub-depends and up/down trigger logic.

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

It doesn't work this way -- the code flow would have to be completely 
rewritten.

> (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)

Yes, I shot down that idea.

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

This isn't restating hierarchy, this is a first-level ? : trinary 
operation and if those vars go on the ./configure line it can be done on 
the optional_depends line.  We could add a "this if yes" "otherwise 
this" setup to config_query/etc. for the non-dependency case into the 
existing sorcery code without reimplementing,

> 
> 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.
> 

There are, see mutt, linux, etc.

> 
> 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;}
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss