No subject

nagios-users (www.nagios.org) mailing list.  There have already
been a few discussions encouraging the author to rewrite Nagios
so that the config files are in XML.  Because of the modular
nature of Nagios, the "path of least resistance" option which
seemed to rise to the top, was one of letting someone write
a preprocessor.  This preprocessor would parse XML files and
produce native Nagios config files.  This has 2 benefits:  it
allows the core developers to continue working on Nagios without
getting sidetracked, and it will (eventually) allow XML
folks to work within their familiar domain.

The yum project doesn't appear (to me) to be on the same level
of development complexity as Nagios, so the preprocessor approach
might not be appropriate.  I only make the suggestion as an alternative
to help resolve the "less filling" vs. "tastes great"  debate.  ;)

jc


> -----Original Message-----
> From: Michael Stenner [mailto:mstenner at phy.duke.edu]
> Sent: Friday, May 30, 2003 8:12 AM
> To: yum at linux.duke.edu
> Subject: Re: [Yum] script run idea
>=20
>=20
> First of all, Rob, I suggest that you prepend abstracts to emails
> which exceed 50 lines (maybe that should be 100, I dunno).  How about
> 8 line abstracts, with each line under the standard 76ish character
> limit? :) You can even do <abstract>I demonstrate the
> necessity...</abstract> if you want :)
>=20
> My take on xml is that it should usually be used IFF the primary
> purpose of the data is to be read and written by machine, but human
> reading or writing is considered valuable (but secondary).  The gconf
> stuff would be a perfect example.
>=20
> Let me try and summarize your five points:
>=20
> a) a standard config format would be good, and xml would be a good
>    choice for that
>=20
> b) xml is well understood, other formats are inconsistent (maybe this
>    should be a.1)
>=20
> c) xml is extensible, or MUCH easier to make extensible than
>    most hand-rolled alternatives
>=20
> c) [ you probably meant d :) ] xml is easy to edit by hand
>=20
> d) easy multi-purpose parsing and machine-editing
>=20
> Basically, this comes down to a matter of opinion, but I think the
> place where I disagree is with reason c, (the second one).  I think a
> lot of people find xml harder to read and edit than most other
> standard config files.  I find I often have trouble finding the data
> amidst all that markup.  This is just plain subjective, so I don't see
> much point in discussing it into the ground.  However, it's often the
> dealbreaker for me.  If I found xml as easy to read/edit as the
> standard .ini format (like yum uses) then I would be completely with
> you.
>=20
> After all that, let me finish with this:  I don't have an opinion
> about which format should be used.  I don't know enough (haven't been
> following closely) about what it will do, how it will be used/edited,
> and how extensible it needs to be.  I just wanted to share my thoughts
> on Rob's thoughts on xml :)  And to pick on Rob a little.  I wanted to
> do that, too.
>=20
> 					-Michael
>=20
> --=20
>   Michael Stenner                       Office Phone: 919-660-2513
>   Duke University, Dept. of Physics       mstenner at phy.duke.edu
>   Box 90305, Durham N.C. 27708-0305
> _______________________________________________
> Yum mailing list
> Yum at lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum
>=20