[Nagiosplug-devel] RFC: New threshold syntax

[Max]

On Wed, Mar 19, 2008 at 10:59 AM, Andreas Ericsson <ae at op5.se> wrote:
>  Not really. Verbose and easy to read should win out any time, as the
>  syntax isn't supposed to be used daily. It's much more important that
>  it's accurate and that the user is comfortable with the thresholds
>  he/she has specified than that it's possible to cram as many args as
>  possible into an 80 char wide screen.

What are your suggestions, Andreas?  You have given a lot of feedback
on what you like and do not like, what syntax do you suggest?

>  No, that's really, really bad, because everyone will come to the same
>  place and ask for help, so if you get 9 different libraries you'll
>  have 8 of them which no developer knows how to handle. Although I
>  expect that will be a small issue, since 99% of all users will just
>  go with what's default anyway.

Fair enough.

>  I am, in the strongest possible terms. For one simple reason: Bitrot.

Let usage show who wins, provide a few parsing options, see which gets
used the most and then drop the others as officially supported and let
people from the Nagios user community support them if they are wanted.

>  > I agree that forcing order on the threshold arguments from the command
>  > line will frustrate some users and completely goes against the grain
>  > of how 99% of Unix CLI tools work.
>  >
>
>  Not really. find does it that way.

99%, yes, I knew about find.

>  Not stupid, but naive if you think that both of them will be kept up
>  to date, along with the documentation for both of them. Like I said,
>  it's maintenance nightmare to support two different ways of saying the
>  same thing, and doubly so if you want users to know about it.

I do think that if their is enthusiasm among Nagios users to keep them
up, they will be kept up and Nagios is all about choice - flexible
syntax, loads of add-ons and enhancements and points of integration.

No one would expect you to maintain them, you do not think there are
enough Nagios plugin writers available to support two parsers?

>  What about use?

I agree, present a few options and let 'use' decide which wins in the long term

- Max