<html><body class="ApplePlainTextBody" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>On May 10, 2012, at 2:24 AM, Henning Rogge wrote:<br><br><blockquote type="cite">On 05/10/2012 05:09 AM, Hans-Christoph Steiner wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Ok, I just finished tracking down all of the information that I thought<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">might be at all useful. Mostly, I dug thru the txtinfo and httpinfo<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">plugins. I pushed my changes, so they're in olsrd.git now.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Attached is an example dump from the current jsoninfo plugin from a mesh<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of four nodes, which I made by running this:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">curl http://localhost:9090/status/config/plugins/> all.json<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* /status gives all of the data of things that change during runtime<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* /config is the complete olsrd_config struct output as JSON<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">* /plugins is the complete plugins info from olsrd_config<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I would love feedback on all of this. I tried to use descriptive names<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for all of the JSON keys, please make sure I got them right. Do the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">data types and structures make sense? etc.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Why is this kind of translation necessary:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">abuf_json_float(abuf, "linkCost", atof(get_linkcost_text(my_link->linkcost, false, &lqbuffer2)));<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">You first convert the raw linkcost into text, then into float, then into text. Why not skip two conversions?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">It might even be a good idea to add another field "rawLinkCost", which just includes the 32 bit unsigned integer. That is more easy to parse for a program.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What do you think ?<br></blockquote><br>So far, I mostly just remixed the txtinfo and httpinfo code to produce valid JSON. Now its time to see what doesn't make sense anymore. Sounds like you found something :) Also, I'd really like to have this use key names that make sense and are descriptive, and have the data in a format that is standardized and easy to use. I don't know enough about these guts to know exactly how to do that, so I'm hoping for lots of feedback.<br><br>I updated the "cost" data points to use the int directly, and I named the JSON keys after the variable names: linkCost, rtpMetricCost, tcEdgeCost, tcPathCost. Are these costs directly comparable? If so, then I'd name them all "cost".<br><br>As for get_tc_edge_entry_text() and get_link_entry_text(), it seems that each lq_plugin implements the guts differently, some using floats, some ints. So I can't see how to handle that in a generic way.<br><br>.hc</body></html>