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 <[email protected]> wrote: > > > 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
