Re: [B.A.T.M.A.N.] Alfred batadv-vis json conformance

Simon Wunderlich
2013-10-02T13:05:48Z

[-- Attachment #1: Type: text/plain, Size: 6821 bytes --]

Hey Andrew,

On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:
> Hi Folks
>
> I will soon need to parse the output of batadv-vis -f json. However,
> its not really, json, it does not pass json validation tools. Hence i
> doubt i can use the standard parsing libraries.

Yes, it is only JSON line-wise, but not the whole output. This output format
however is the same as we have/had in the batctl JSON output which comes
from the kernel (I think that was your contribution in the first place?).

Therefore I'd like to leave this old format as it is to allow communities
to seamlessly switch from batctl json vis to alfred-vis.

>
> There has been discussion similar to this recently, about alfred -r,
> and a proposal to change the output to make it json conforming. I
> would like to raise the discussion of modifying the vis output from
> batadv-vis.

Regarding the other discussions, I'm still waiting for new patches from
Nils. ;)

I don't want to "parse" any transferred data in alfred, but we can do this
for tools like alfred-vis ... And yes, the default json output is
currently not JSON-compatible for binary data...
>
> I have a simulation system of four nodes, fully interconnected, with
> one double link, but is rather sort of translation table entries. The
> current vis output is:
>
> { "primary" : "02:00:00:00:12:01" }
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" }
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5", "label" : "TT" }
> { "primary" : "02:00:00:30:10:01" }
> { "secondary" : "02:00:00:00:10:01", "of" : "02:00:00:30:10:01" }
> { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" }
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e", "label" : "TT" }
> { "primary" : "02:00:00:00:11:01" }
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
> { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66", "label" : "TT" }
> { "primary" : "02:00:00:00:13:01" }
> { "secondary" : "02:00:00:30:13:01", "of" : "02:00:00:00:13:01" }
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }
> { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" }
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4", "label" : "TT" }
>
> My first suggestion for a conforming output would be:
>
> [
> { "primary" : "02:00:00:00:12:01",
> "neighbors" : [
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" },
> { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> ],
> "TT" : [
> { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5" }
> ]
> },
> { "primary" : "02:00:00:30:10:01",
> "secondary" : [
> "02:00:00:00:10:01"
> ],
> "neighbors" : [
> { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" },
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" },
> { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> ],
> "TT" : [
> { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e" }
> ]
> },
> { "primary" : "02:00:00:00:11:01",
> "neighbors" : [
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
> { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }
> ],
> "TT" : [
> { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66" }
> ]
> },
> { "primary" : "02:00:00:00:13:01",
> "secondary" : [
> "02:00:00:30:13:01"
> ],
> "neighbors" : [
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" },
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" },
> { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" },
> { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" }
> ],
> "TT" : [
> { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4" }
> ]
> }
> ]
>
> 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).

Maybe we can change the names to:
* for neighbors: router->nexthop
* TT: "gateway" -> "client", "router" -> "node", maybe also change TT to clients?
>
> I would like suggestions and comments from others with more experience
> with json. Is the basic structure O.K. Are there better names to use?
>
> There is also the issue of can we change the format of the current
> output. Is it considered an ABI? Should I add a third format string
> which can be passed with -f to produce true json, and leave the old
> format as is, for backward compatibility?

As explained above, I'd like to keep the old format, so a third format
string should be used. It would be nice (if possible) to consider BATMAN V
at this point too to avoid adding many more formats in the future, but
generally I'm okay with adding new formats.

Thanks,
Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]