DragonFly kernel List (threaded) for 2003-12
Re: configuration files
Well, I wasn't necessarily arguing for using xml or any other specific
format. But since I'm bored at work, I'll put on my bikeshed helmet and
throw in my thoughts.
I think any type of structured format would be better than the mish-mash
of formats that are in use today. If the tools were good enough, most
people wouldn't care whether it was xml, name/value pairs, or whatever.
As you mention, most of the simpler tools wouldn't benefit much. Most
of the benefit would come from more complex tools. As someone has
mentioned, apache is moving towards an xml config file.
I'm not usually one to ride the xml bandwagon, but in this case I think
it would be a logical format to use. Since it's text, you always have
the escape hatch of editing it manually. But since it's structured, it
facilitates syntax checking and using tools to create them.
I've been on several projects where it was decided to use name/value
pairs rather than xml because it was "simpler". At first this was true.
But then we needed entries to have multiple values, so we added a bit
of parsing for comma separated values. Then we needed a way to group
multiple entries, so we created "meta-entries". Before long, the format
was just as complicated as if we had used xml, and not nearly as well
defined. I think this is a common occurrence as the tendency is for a
tool to grow more complex than initially intended.
Now the benefit of all this would not be realized unless real tools were
developed to use it. For instance, graphical interfaces to remote
administer machines, etc. As I said before, such tasks are really a
project in themselves. That's why I think it's best for such config
file changes to happen in another OS project devoted to such goals.
Jeroen Ruigrok/asmodai wrote:
-On [20031211 19:32], Richard Coleman (Richard.Coleman@xxxxxxxxxx) wrote:
My guess is something of this nature will never happen within the
confines of current BSD projects. You would never get enough people to
agree on the details, and the resulting bikeshed discussion would be
legendary. This is not a slam on any current project. Such a change
would be very disruptive with very little short term gain (most of the
gains would be long term).
It's even simpler:
XML is for ensuring data portability. A configuration file, in plain
text, does not even qualify for this.
Just using XML to write a configuration file in without using anything
to do validation or schema control on top of it is a waste of a
perfectly well-working system into something which just has the latest
buzzword attached to it.
I still need to see the advantage of doing: