[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: [RFC 1/6] Non-Turing-complete configuration files.



On Sat, 2009-01-17 at 21:31 +0100, Árpád Magosányi wrote:

> > Real crux of the matter: If you accept free-form input, it becomes
> > inordinately more difficult to write any sane GUI, or write-back of
> > changed config options. (Since the config file might be arbitrarily
> > complex).
> 
> Reading configuration for the configurator GUI is a non-issue: a good
> configuration GUI never do that. It either uses the configured
> program's config reader routines (in our case the interpreter), or
> generates the config from a different source.

You're missing the point.

If we allow config to be turing complete, a valid config file might be:

(set! foobar (* 2 43))
(set! blah (+ foobar 99))
(page-width blah)

There is no way to represent that in a GUI which would offer a page
width edit box in number + coordinate units. Even if you were to wipe
out the (page-width blah) and re-write as (page-width 185), you'd be
breaking the user's intended config and leaving un-needed variables
assigned in the config file which will float about in the scheme
interpreter after being assigned.

By "non turing complete" we're talking about the definition of what is
legal syntax in the config file, not what parser we need to handle it.
You can continue using a scheme interpreter, or use one of the many
s-expr parsers (smaller).

What we _are_ saying, is that your _config_ file will _not_ be executed,
and any intelligence is based on defined primitives which the program
will provide - NOT by the scripting language. (Sandboxing is then
trivial - which it is not when we're using guile).

> Unfortunately nowadays the average firewall admin have absolutely no
> clue about network, protocols and security, so a GUI is a must.
> And yes, firewall config is different than config of some tools: the
> configuration in itself is a modelling problem, in a world of several
> object classes and their interrelations. So our GUI just writes Zorp
> config, does not read it.

Since our config files are expected to be user-writable, we have to
define a legal syntax. Parsing the processed results of an arbitrary
_program_, then treating that as the basis to write out a flat config
file is not on.

All we are doing is suggesting that the config should not be a program -
in which case we can guarantee that it is simple to write back a
modified version without trampling anything "clever" the user embedded
in the same file.

(Programmed scripting is still allowed - but we _absolutely_ want them
to be separate from config.)

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user