[j-nsp] certain commands executed on CLI provide additional information over corresponding RPCs

[Saku Ytti]

Ah.

Your point is that the strings are different? CLI says 'Rtr' tag says
'isrouter'?

I can't relate this being a problem, sorry. The data is there, you can
classify and reprint it as you wish.

On 9 March 2018 at 12:37, Martin T <m4rtntns at gmail.com> wrote:
> On Thu, Mar 8, 2018 at 11:51 AM, Saku Ytti <saku at ytti.fi> 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 <phil at juniper.net> 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 juniper-nsp at puck.nether.net
>
>>> 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



-- 
  ++ytti