I agree that the current format is very easy to parse for a human, which is a benefit. I am struggling to have a machine parse this though.What do you think of providing the same data over json to make it better parsable?The format of the monitoring interface is well defined : it's a series of lines of the form keyword id key value key value ... where each key/value is either space separated, or a string within double quotes. This format is extensible (we can add new keywords and new keys at any time), and it's also easy to parse by a human (Antonin and I have just spent much of today telnetting by hand into Babel's monitoring interface). So I'm not convinced that switching to JSON would have any benefits. Please let me know if you disagree, I'm not fundamentally opposed to adding a new command "monitor-json" if you think it's desirable, but I'd rather avoid the added complexity.
Just from the switch for babeld-1.8.0 to master a new field got introduced for neighbour lines. This caused my sscanf-based line-parser to break:
int n = sscanf(line, "%ms neighbour %*x address %ms if %ms " "reach %x ureach %*x rxcost %d txcost %d cost %d", &action, &address_str, &ifname, &reach, &rxcost, &txcost, &cost); The whole code for the parsing is in a library that lives here: https://github.com/christf/libbabelhelperMaybe I am just not parsing this the easy but the hard way. So before going into the benefits of json, maybe we can see if there is a manufactoring error with my own approach in parsing this.
So instead of running sscanf like above, I guess I could strtok the line and just match for known keywords and extract their values, however blanks in values would be a problem to this approach. Do we really need to deal with blanks in values?
Christof -- () ascii ribbon campaign - against html e-mail /\ against proprietary attachments
Description: PGP signature
_______________________________________________ Babel-users mailing list Babelemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users