[zeromq-dev] Statistics protocol (ESTP) v0.2

Paul Colomiets paul at colomiets.name
Sun Jun 10 14:12:52 CEST 2012


Hi Schmurfy,

On Sun, Jun 10, 2012 at 1:11 PM, Schmurfy <schmurfy at gmail.com> wrote:
> I am really not sure on this, while I like sensible defaults when writing
> code to speed things up
> I prefer protocols to clearly say what they try to express, if there is a
> "default" I agree that gauge
> would be the most common type but it introduces one problem for me: you have
> to deal
> with the presence or absence of this field and as you mentioned the number
> of fields
> will change between a gauge value and a counter value. How do you handle
> multiple flags scenario without separator ?
> "43btgh" would really be ugly to parse.
>

Well, I consider it type, not flags. So the type is only one. Being it
non-letter gives ability to use letters to describe flags, or
parameters easier.

> If you know the value will always be something like:
>
> 23.4|ghty
> (with "hty" being hypothetical flags and g the type)
>
> then you can just split the string with "|" and look for known flags in the
> second part which
> becomes a little harder is the flags are directly added at the end of the
> value ("34.56ght") since
> in this later case you need to do some magic to separate what is two
> different informations for me.

I've tried to implement a collectd plugin:

https://github.com/estp/collectd-zeromq-estp

It was easy. Even in C. In scripting languages there are even more
tools (e.g. regular expressions).

> If there is a separator (the pipe here) then having gauge as default bother
> me less because a quick
> split will reveals there is no flags defined without further operations.
>
> I agree mostly on the extensibility but if you wanted to add more options to
> the value the logical choice
> would be to add other one letters flags in this case.
>

No, the important point is that lazy parser can skip parameters, and
almost always be right.

> Until now I never needed to add much to the value itself and its type,
> knowing counters size may be
> useful to detect overflow though but I never worked with counters.

This is also the reason why gauge is default. Most people will just
use it, without thinking about types.

> I think the real question is what informations we could want linked to a
> value, allowing anything and everything
> to be added leter may not be the more efficient way ;)
> (that's funny because some parts of the discussion start to look like low
> level concerns for zeromq /libxs)
>

I've added forward compatibility section. Can you look through?


P.S.: Latest spec is now at
https://github.com/estp/estp/blob/master/specification.rst

-- 
Paul



More information about the zeromq-dev mailing list