On Thu, Mar 8, 2018 at 11:51 AM, Saku Ytti <[email protected]> wrote: > Hey Phil, > > I'm hijacking this for a bit. > > You have | display json and xml, I assume json was relatively modest > amount of work, as you have formal source of data, so someone only > needed to write translator, without being aware of all context to > support | display json, which also means, no one needs to do any work > to get display xml or json to work on new command introduced? > > If this is remotely true, shouldn't it be equally possibly to present > all data over SNMP which is presentable as JSON and XML? There are > bunch of gaps on relatively important stuff, which I'd love to see > available in SNMP. This week particularly I was frustrated to find how > 'show class-of-service fabric statistics' is not available over SNMP. > Perhaps introduce some CLI-MIB where all json/xml supporting commands > are generated in OIDs and command in CLI to ask OID for particular > command? > > > > > On 8 March 2018 at 07:26, Phil Shafer <[email protected]> wrote: >> Martin T writes: >>>I have noticed that certain commands executed on CLI provide some >>>additional information over corresponding RPCs. For example "show ipv6 >>>neighbors" or "show system storage" on CLI show column names while XML >>>output does not contain this data. Why is that so? >> >> Both the CLI and RPC content contain the same information, but the >> CLI takes the data supplied by the RPC and displays it using rules >> specified by the developer. These rules include column headers, >> field titles, and other gritty little details. >> >> But these are "display" features. The API is meant to allow access >> to the data, and to make that data the same data used by the CLI, >> so the API is complete, up-to-date, well-tested, and useful. >> >> If you want to use the API to get pure text data, we do have the >> 'format="text"' attribute that can be put on an RPC. >> >> Thanks, >> Phil >> _______________________________________________ >> juniper-nsp mailing list [email protected]
>> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > ++ytti Hi Saku, > I don't follow you, the 'column' names are not needed, as they are in the > tags? Column names are not in the tags. For example, consider a use-case where you want to print the output of "show ipv6 neighbors" similarly to table format of BSD column utility and you would like to use the same column names as the output of "show ipv6 neighbors" CLI command. One way to do this is to manually create a node-set variable for the column names: "var $column_descr := { <ipv6-nd-entry> { <ipv6-nd-neighbor-address> "IPv6 Address"; <ipv6-nd-neighbor-l2-address> "Linklayer Address"; <ipv6-nd-state> "State"; <ipv6-nd-expire> "Exp"; <ipv6-nd-isrouter> "Rtr"; <ipv6-nd-issecure> "Secure"; <ipv6-nd-interface-name> "Interface"; } } ..and generate another node-set variable using "get-ipv6-nd-information" RPC and finally use the union operator(|) to find the longest row in each column and print the output accordingly. Phil, > Both the CLI and RPC content contain the same information, but the > CLI takes the data supplied by the RPC and displays it using rules > specified by the developer. These rules include column headers, > field titles, and other gritty little details. Thanks! That's what I suspected. Looks like for example in case of "show ipv6 neighbors", cli process calls nd6info binary which contains the column names and statically set printf format string. regards, Martin _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
