What do you think of providing the same data over json to make it better

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

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

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, 

The whole code for the parsing is in a library that lives here: 

Maybe 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?


()  ascii ribbon campaign - against html e-mail
/\  against proprietary attachments

Attachment: signature.asc
Description: PGP signature

Babel-users mailing list

Reply via email to