> Hi Andreas, hi list,
>
> agreed. It does not make much sense for Nagios itself to use the XML
> file, that is why I suggested (sorry for this dirty ASCII art):
>
> API -> description -> documentation
>
> and not
>
> documentation
> ^
> |
> description -> API
>
> Anyway this is much better than
>
> API ------ manually intervention ---------> documentation
>
Umm, I'm not so sure, because you still have
API-in-code -> manual intervention -> documentation
except that in your case, the manual intervention consists of updating
the XML description and then run some script to generate the docs
rather than updating the docs directly.
> So you just have to maintain the description ofcourse with some
> details for usage and meaning of the defined commands and than
> generate your documentation out of it.
>
I fail to see how that is different from maintaining the documentation.
The same bitrot problems apply, except now you have the trouble of bugs
in the documentation generator too.
> After implementing the CLI my next step will be to generate the
> documentation. May I therefor copy some command descriptions out of
> the actual documentation into my XML file? This is just for demo
> purposes. If you like the result we can discuss further steps.
>
I'm sure you may. The nagios docs are under the GNU docu GPL, afaik.
> Ofcourse XML is a little bit longer but in my opinion it is the most
> flexible and understandable format.
No. It's less flexible than plaintext and (to humans) a lot harder to
read too. For computers, something like windows .ini-file format is
one of the easiest to grok. XML is just an addon to HTML with a strict
standard.
> XML parsing in Java is not really
> problem, in C nobody wants to do it actually.
I don't know about Java, never having forgiven it for its rotten
performance and bulkiness. Imo, C is the right language for Nagios. It's
a system application doing heavy lifting, and quite a lot of it in some
networks. Having parts of it in Java would be wrong, even if that part
only was responsible for propagating passive check-results from one end
of the network to another, and command-line tools are hardly ever written
in java because of the ridiculous start-up costs associated with having to
launch a virtual machine to run even the "hello, world!" program.
> Maybe you got this wrong: I never wanted to understand Nagios XML code
> nor writing XML code into the pipe.
>
Then I did understand you wrong.
> If have some time at the weekend to go further. The CLI is just a
> first little step. Documentation generation will be the next.
>
Ok. Should be interesting. Just so you know though, you'll most likely have
to follow Nagios indefinitely if you want your XML documentation to be kept
up to date, as I have a hard time imagining Ethan bothering with updating
it to keep the external command list documentation complete and correct.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]