On Thu, Oct 03, 2013 at 08:09:08AM +0200, Martin Hundebøll wrote:
On 2013-10-02 18:01, Antonio Quartulli wrote:
On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
I'm also wondering if label and gateway could have more meaningful names? TQ and host? Also, is TT the best?
Hm, that is a good question. We also have the batman v with new metrics coming up, I'm not sure how to handle these (maybe Antonio has some idea?). It is not the TQ-value in the label after all, but some kind of ETX-converted value (255/TQ if i remember correctly).
I think the ETX stuff comes from OLSR (but I don't know the details).
I agree with Simon that we should find a generic name (e.g. metric ?) but I am not sure we can represent this value in a "algorithm-generic" fashion (and maybe we don't want to).
May I suggest that the cjson output includes an entry to tell the version of the batman-algorithm?
Users might want to do different map overlays (or whatever) depending on the available metric(s).
Hi Martin
I did think about that, but i'm not sure how. The cjson format is the simple bit. I can add an outer layer with more key:value pairs. Something like this:
batadv-vis -f cjson { "algorithm" : 4, "source_version" : "2013.4.0-g6b13699", "vis" : [ { "primary" : "fe:f0:00:00:04:01", "neighbors" : [ { "router" : "fe:f0:00:00:04:01", "neighbor" : "fe:f0:00:00:05:01", "metric" : "1.000" }, { "router" : "fe:f0:00:00:04:01", "neighbor" : "fe:f0:00:00:03:01", "metric" : "1.008" } ], "clients" : [ "00:00:43:05:00:04", "fe:f1:00:00:04:01" ] }, ... ] }
But how do we determine the algorithm version? For the moment it can simply be hard coded. But for version 5? Will the over-alfred format change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for algorithm 5?
Thanks Andrew