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

Re: Configuration management, revision 3



Previously Antti-Juhani Kaijanaho wrote:
> Let's start with a very simple package, xyzzy.  The only thing it
> needs to know is whether the system clock is set to UTC or not.
 
> How to present this to the frontend?  Clearly we need to give it a
> named aggregate of pairs (consisting a label and a datum).  One pair,
> for example, might be labelled "type", referring to the type of values
> wanted, and its datum could be "yes/no".

Agreed. 

> The syntax for communicating the aggregate is not really relevant to this
> illustration, but for clarity's sake I will need to pick one.  The one I pick
> owes much to Lisp and Scheme.  It is not the only option, however.

I happen to dislike a lot of parentheses such as lisp uses.. programming
in miranda will do that to you.

> The attributes are, again, all within their own parentheses.  They
> consist of a keyword identifying the attribute (here "type", "query",
> "explanation2 or "default") and of the attribute datum.
 
> A more complex package would simply put several of these aggregates in
> a row.  For example:

(nesting example removed)

> This is all given to the frontend in one batch.  It will then use some
> other means to give the config module the answers.

Everything should indeed be given to the frontend in one batch as I've
realized. This would make the frontend much more flexibly, as well as allow
us to make the decision-process more powerfull.

> You probably think that the scheme I outlined above is not powerful
> enough to handle your example.  You are right.  We need a way to
> express the interdependencies between the data.

I was thinking about a language which seperates the two: first you 
declare all variables you want to use and give each a priority. In the
next section you state dependencies between the variables and possibly
a decision process.

> I realize that this language requires a more sophisticated parser than
> Akkerman's original, but IMO it would be worth it.  And I don't think
> the parser needs to be /that/ sophisticated :-)

I happen to like playing around with parsers and compilers. I'll see if
I can come up with a nice design :). Even if the parser is (somewhat)
complicated, we only need to implement it once.

Wichert.

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

Attachment: pgpRPijidCV2b.pgp
Description: PGP signature


Reply to: