Re: Use of XML for config files

[Stephen Leake <stephen_leake@acm.org>]

dennison@telepath.com (Ted Dennison) writes:

> Volkert Barr <barr@cs.tu-berlin.de> wrote in message
> news:<3CFC5DB2.A21DCF61@cs.tu-berlin.de>... 
> 
> > the Configuration Packages! If there is a consensus that XML is needed,
> > the Spitbowl Package must be ported! 
> 
> I don't think this would be nessecary or a good idea. Making our own
> Configuration XML parser is not out of the question. Parsing any XML
> language that anyone could ever come up with is a very different task
> than parsing a specific XML language. Making an XML parser customised
> to the configuration XML language (whatever that would end up being)
> may be more work than using ACT's XML reader, but it wouldn't be an
> undoable effort.

Yes.

> We really only need to make the package *spec*s portable Ada. It
> would be nice to have a portable reference implementation too, but
> its not an absolute nessecity to have one, as long as its *possible*
> to make one.

Exactly.

> However, I agree with you that its probably more work than the task
> requires. I think it would be silly to use XML, unless we are
> getting something out of it that we can't easily get out of other
> grammars. PR is *not* a sufficient answer. :-)

Yes. However, I think the potential for an application to "grow" the
config file beyond the Config_File API, and use a "full" XML parser
instead, is a Good Thing. Clients with installed config files would
not need to change them when the app is upgraded.

> What that means is that if we were to use XML, we should support
> both user-defined configuration item attributes 

Just because XML supports this, doesn't mean the Config_File API
should. We're looking for a simple subset. If the app decides it needs
these, it can go to a full XML parser.

> and some kind of object nesting (configuration items defined within
> other configuration items). 

Actually, the "multiple levels" is precisely the same as nested
objects. That is:

foo.bar.item_1
foo.bar.item_2
foo.figs.item_1

is the same as:

object foo 
   object bar
      item_1
      item_2
   end object
   object figs
      item_1
   end object
end object

Hope that's clear :).

> I haven't really heard anyone seriously arguing the usefulness of
> this stuff.

We all have :).

> If we are to stick with simple attribute-value pairs, then XML would
> be major overkill.

In what way? I have a very small package that parses the subset of XML
that I need to meet the Config_File spec (Glib.XML - 671 lines in the
body). What's wrong with that?

-- 
-- Stephe