[Nagiosplug-devel] Suggested alterations to the Performance Protocoll

[Yves Mettier]

> Ben Clewett wrote:
>
>> Looking back at suggestions from my original email and discussion:
>>
>> 4.  Addition of macro's.  NaN = No value.  -INF and +INF to be used in
>> range specification.  Agreed.  (?)
>
> I do still think some token to indicate it is a macro is appropriate

For INF and NaN, I don't consider them as macros, but as values.
Look at the ethymology: macro stands for macro command. And INF and NaN are not commands !

> I used "=" in my conceptual discussion this morning, but that obviously
> won't work because we alreadty use "=" in the guidelines.
>
> How about @NAN@, @NULL@, @+INF@, @-INF@

I like "@" (because I use autoconf/automake), but it won't work here because @ is the
keyword to invert a range.

> Or [NAN], [NULL], and so on.

[ and ] will be ambiguous in the documentation. They mean that the contents is optionnal
in the doc. I prefer no interaction with the doc, even if there should be no problem
here.

Any reason not to use $ like nagios does ? $TIMET$ :)


> Or is there a general reason why some sort of tokens won't work?

Back to the debate. For me, there are now 2 questions.
1/ Are NaN and INF macros ? I consider that they are values, and should be recognized as
values, like some strtod() implementations do. I also suggest to use the values that
glibc uses:
printf("%lf %lf\n", (0./0.), (1./0.));
I'm not sure (I have no glibc here), but the result is something like this:
NaN inf

If we consider them as values, there are only "NaN" and "inf" to recognize before using
strtod. We don't need an identifier.

2/ What macros do we need besides NaN and INF ? I read about "protocol_version",
"start_time", "end_time"... Those are not macros but keys. There is no need for a
protocol change here. The only thing that can be done if you want to reserve such keys
is to write it as a footnote in the doc. All parsers will be compatible with that, even
if they don't know that those are reserved keys. So here is my question: what keywords
do we need to consider them as macros, in other fields than the key field ?

>
> (I should not that if there is no range provided, it is genereally
> assumed to be infinite in the current plugin implementations - in other
> words, the philosohy has been to ry and be diligent in providing limts
> whenever they can be)

About inf, we already have the "~" reserved symbol. Here, we are talking about using
"inf" instead of "~" in the range field.
And NaN cannot be used in ranges. How can you define a range with "NaN" ? :)
On the opposite, inf cannot be used in values. You can't measure the infinite. If you
cannot measure something finite, the result is "NaN", not "inf".
Well, I already said that, but I feel important to write it again.

>
>> 9.  Limit protocol to just numerical data:  No.  But will not be
>> supported by some storage programs.  (Yves performance parsing engine to
>> allow such programs to do what they like with this data.  Hows this work
>> going?)
>
> Right - programs that are built for graphing would be expected to ignore
> such data. But that does not give license to design the guideline such
> that nothing but graphing can ever be done with the data.

If I understand well, you are not against not-numerical data (i'm not against either).
If we do that, we need a separator between the value and the UOM. See my previous mails
about that (and about my suggestion to move "min;max" to a range if the protocol changes
and the compatibility is lost).

Yves


-- 
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -