On 10 June 2012 14:12, Paul Colomiets <[email protected]> wrote: > 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). >
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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
