Re: Use of XML for config files

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Stephen Leake wrote:
> 
> > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:
> >>Stephen Leake wrote:
> >>
> >>>However, I think a sufficiently small subset of XML is ok. I'll be
> >>>posting a complete example Real Soon Now :).
> >>
> >>Aaarrrggggghhhhhhhh!!!!!!!!!
> >>
> >>When will people learn that config files should be readable and
> >>understandable.
> > Yes, that is one of the requirements for Config_Files.
> > You seem to be implying that XML is inherently _not_ readable, or
> > _not_ understandable.
> > Many people here disagree.
> 
> 
> If your goal is to provide a configuration file that is as simple
> as a .ini file, then I think any subset of XML is a poor choice.

Not quite; see the web page:
http://users.erols.com/leakstan/Stephe/Ada/Config_Files/config_files.html

Your statement is close, but not quite right. For example, ini files only
have one layer of hierarchy; I'm now requiring more (that seemed to be
the consensus here).

> Here's one reason why:
> 
> It _does_ add complexity. As Ted mentioned in an earlier post, if
> you had to describe to a person who barely can handle an editor
> over the phone (the worst kind of support position), you would
> have to ask many questions about whether a tag was properly closed
> etc. You'd have to start by describing how tags open and close
> for starters.. and they probably wouldn't really get it anyway.
> Then going beyond that to nested tags - arg!

Yes. Have I captured that sufficiently in my "Disadvantages of XML
format " section?

> I for one, would hate to be in that sort a support role. But even
> ignoring support roles, it is easier to describe an ini file change,
> than a XML change in a document.

Ok, if we assume people are not familiar with tag syntax.

Quoting special symbols is a bigger problem for me.

> BUT, if your _goal_ is a hierarchical structure like the Windoze
> registry, then I think you should be prepared to accept binary and
> focus on it at the API and implementation level. 

My goal is somewhere between ini and registry, but much closer to ini.
A primary requirement is editing with "simple text editors".

> The way to make it user configurable, is to provide a regedit type
> of tool that is general enough to handle most cases. Perhaps make it
> type extendable that is supported by dynamic shared libraries.
> Furthermore, it is then possible to layer some ACL type of security
> on your values.

Might as well just use the registry, or Gnome gconf. 

> I personally would like to see this registry-like data in a postgres
> database, with a smooth API to access/create/modify values. The
> disadvantage of course, is that this would require that Postgres be
> running on all hosts where your application goes. There is a fellow
> that is attempting to put all Linux configuration values into a
> Postgres database. I think I saw this in a Linux publication last
> fall. This approach will then make it easier to configure all
> aspects of the system from a GUI.

Look at the Gnome gconf stuff (on sourceforge).

> So many have already said here: your implementation will depend upon
> your design goals.

Which is why the requirements (goals) are listed on the web page.

-- 
-- Stephe