Hi Schmurfy,
On Sun, Jun 10, 2012 at 1:11 PM, Schmurfy <[email protected]> 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
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
