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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
