Re: Why not XML based configurationfiles?
From: P.T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 07/05/04
- Next message: Robert Heller: "Re: Linux-friendly DSL providers"
- Previous message: P.T. Breuer: "Re: Why not XML based configurationfiles?"
- In reply to: Mats: "Re: Why not XML based configurationfiles?"
- Next in thread: John-Paul Stewart: "Re: Why not XML based configurationfiles?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 5 Jul 2004 04:29:14 +0200
Mats <spamenot.mog.pettersson@telia.com> wrote:
> P.T. Breuer wrote:
> > Mats <spamenot.mog.pettersson@telia.com> wrote:
> >
> >>The point is to make it easier for a computer to parse, since that makes
> >
> > No that isn't the point. I don't care how difficult it is for a
> > computer to parse (and the computer doesn't either).
>
> Well, writing an algorithm that do regular expressions is more
I don't understand what you mean. What have finite state machines (aka
"regular expressions") got to do with it? They are usually used to
define lexical tokenisers. Presumably you would always use the same
tokeniser no matter what your grammar or parser was.
> complicated than one just splitting variable=value pairs (for example),
I don't understand what you mean.
> you also have the problem with tags that span over multiple lines, that
There's no problem with that ... what's the difficulty supposed to be?
> i think is allowed in XML. That's why i want to have it more strict. If
> one f***k up with parsing you might get buffer overruns and whatever (at
> least if you do a utility in C).
I think from the amazingly ig'rant stuff above that you don't have any
knowledge of parsing or parsers. Well, I do. I am the author of a
compiler compiler, used worldwide for about 15 years (preccx). No
"buffer" is involved. Parsers are easy to generate by anyone who has
any training in computer science.
> >>it easier to do a configurationutility/editor that can manage several
> >
> > No it doesn't. Parse = parse. Where do you get the weird idea that
> > computers have any more or less "difficulty" doing one thing or
> > another? You can't mean that - what you must mean is that humans have
> > difficulty writing the parser. Uh uh - no they don't. Writing parsers
> > is peasy, and you only have to do it once, and you can use it on all
> > your config files that are written that way.
> >
> > How many different formats of config file are there? Five? And 90% of
> > them are just "foo = bar".
>
> If it's so easy, how come only Webmin does a descent job with it?
When did you stop beating your wife. What's "webmin"? Isn't that some
useless gui config utility for lusers? Why not just edit the files in
question yourself?
As to why "only webmin", I don't know even why one should use it! But
whatever parsing it does is the trivial part of its programming.
> > And I don't want to use a special editor - I want to do it myself!
>
> You still can.
NO I can't - XML is unreadable for humans.
> > Ooohhhh - you want
> >
> > <variable name="foo" value="42">
> > <help>
> > foo describes the frobnick option and can be set to bar or baz. Most
> > users will want to set it to bar, unless they're running more than 50
> > instances of the server.
> > </help>
> > </variable>
> >
> > Or would you prefer ...
> >
> > <stanza name="foostuff" version="1.1" author="A.N.Other">
> > <variable name="foo" value="42"/>
> > <help name="foo">
> > foo describes the frobnick option and can be set to bar or baz. Most
> > users will want to set it to bar, unless they're running more than 50
> > instances of the server.
> > </help>
> > </stanza>
>
> Yes! The last one above is sort of what i wan't. but you should also ad
> the options in tags, so there is no doubt what values the variable can
> have, like (in the descriptor part):
You also want a unique identifier for each help text, as well as its
label. Maybe versioned. ANd then let's not forget the locale
designator.
> <descriptor>
> <variable name="Color" vartype="options">
> <help>You can only use Green and Red Color</help>
> <option value="Green">
> <option value="Red">
> </variable>
> </descriptor>
You forgot the lang="C" bits! And you are messed up already because
what you wanted was to restrict the type of "variable" to an enumerated
list, defined in the xml schema.
>
> or if XML is not to be, maybe something like:
>
> <descriptor>
> define_options Color:"Green","Red";
> define_help Color:"You can only use Green and Red Color";
> </descriptor>
>
> Now you know exactly what values is allowed to go in that variable and
> how they are spelled. In the actual data part, you have:
If you use XML, you want to learn about enumerated types! The above
seems to be part of a description section of the config file.
> <configuration>
> <variable name="Color" value="Red"/>
> </configuration>
Incomprehensible.
> <configuration>
> Color="Red"
> </configuration>
Eh? Oh, non-xml.
> This is the part of the file you change if you edit it, f.ex you can
Now you have description help and config in different parts!
> > Then choose 5 particular standards and implement parsers for them.
> > Trivial.
>
> Yes, maybe. But the point is not just the parser. It's also to make
> shure that the options is properly explained for each variable, so you
The type would just be "string", and nobody would bother documenting
which string. Using XML does not enforce it.
Peter
- Next message: Robert Heller: "Re: Linux-friendly DSL providers"
- Previous message: P.T. Breuer: "Re: Why not XML based configurationfiles?"
- In reply to: Mats: "Re: Why not XML based configurationfiles?"
- Next in thread: John-Paul Stewart: "Re: Why not XML based configurationfiles?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
