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

[Schmurfy]

Latest version looks fine :)
I will try implementing it on one project tomorrow see if I find other
potential problems.


On 11 June 2012 12:21, Schmurfy <schmurfy at gmail.com> wrote:

>
>
> 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/20120613/32743e8d/attachment.htm>