Current-Users archive

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

Re: sysinst split project - The Configuration File

At Sun, 13 Dec 2009 15:56:44 +0100, "Volker A. Brandt" <> 
Subject: Re: sysinst split project - The Configuration File
> Alexander Nasonov writes:
> > David Young wrote:
> > > Use XML for the configuration.  That ensures that the configuration is
> > > queryable/transformable with NetBSD's forthcoming xmltools.
> >
> > I wouldn't recommend XML route. Write a user-friendly lua script
> > instead.
> How many people know XML?  How many people know lua?

I'm not sure that's relevant, but regardless that's an apples
vs. oranges question.

You must ask how many people know XML _plus_ the relevant DTDs.

LUA is one language -- XML is a family of languages.

As for trying to count the number of people who "know" one language or
another, well that's a specious argument in this context.  XML syntax
might be easy to know, and a given XML DTD might be simple to
understand, but SGML style syntax overall is a _horrible_ syntax for
both humans and computers to use.  The very fact that you need to use a
set of tools to manipulate it in any way, and the fact these tools
consist of relatively massive amounts of code, is sure evidence of this

> How many tools can process XML?  How many tools can "process" lua?

That question is out of scope for this problem.

You only need a select set of tools for this given task.  Indeed one
needs far fewer tools in this context to make use of lua than one would
need to make use of a relevant XML DTD.  I.e. with lua one needs only
the built-in embedded interpreter (and a text editor) to use lua.  It's
already suggested that one would need at least xmltools, an XML-capable
editor, plus also perhaps some other tools to make use of an XML DTD.

However I dare say a lot more human programmers will have an easier time
of "processing" lua than they will of processing a private new XML DTD.

I think the point also is that sysinst(8) _really_ NEEDS an embedded
scripting language anyway, so also adding a new private XML DTD to the
mess would be a very unnecessary thing to do.  Even if one could find a
widely used DTD to use which matches the requirements needed here would
still mean adding a whole lot of extra crud that's going to be totally
unnecessary when a proper embedded scripting language is also added.

Why does everyone seem want to shout "XML" in answer to such a wide
variety of questions when that isn't even a proper or complete answer to
any possible question!!?!?!?  Only an answer along the lines of
"such-and-such XML DTD" would be even close to suitable and complete.

Meanwhile throwing XML at almost any problem means throwing a huge
amount of extra code and complex tools at a problem where a simple
human-friendly embedded scripting language would easily provide more
than enough features and support to solve the problem, _especially_ in
this case.  If XML in any form is the best answer you can come up with
then you've probably asked the wrong question in the first place --
either that or it's the only tool in your toolbox.

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218 0099

Attachment: pgpjwZsJCxt1m.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index