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

[Schmurfy]

On 10 June 2012 14:12, Paul Colomiets <paul at colomiets.name> wrote:

> 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).
>

I stil don't like being forced to use regexp when a simple split could do
the job just for the sake of allowing
lazy parsers, for a protocol as simple as this I consider you either code a
full parser or nothing, why stopping
halfway ?


>
> > 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?
>
> Looks fine.


>
> P.S.: Latest spec is now at
> https://github.com/estp/estp/blob/master/specification.rst
>
> --
> Paul
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120611/2d980f70/attachment.htm>