Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Aug 2014 08:54:09 +0200
From:      Stefan Esser <se@freebsd.org>
To:        Phil Shafer <phil@juniper.net>, Alfred Perlstein <bright@mu.org>
Cc:        Marcel Moolenaar <marcel@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net>, "arch@freebsd.org" <arch@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Konstantin Belousov <kostikbel@gmail.com>, Marcel Moolenaar <marcel@xcllnt.net>
Subject:   Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML
Message-ID:  <53F1A311.4080707@freebsd.org>
In-Reply-To: <201408151613.s7FGDMmt003567@idle.juniper.net>
References:  <201408151613.s7FGDMmt003567@idle.juniper.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 15.08.2014 um 18:13 schrieb Phil Shafer:
> Alfred Perlstein writes:
>> Can someone explain an actual use case here that makes sense?
> 
> In JUNOS, we support a NETCONF API, allowing NETCONF RPCs (in XML)
> to get hierarchical data back (in XML).  We use this to automate
> management of our devices.  When we parse RPCs, we construct command
> lines that are invoked.
> 
> For example the "show interfaces terse" command in in the CLI is
> available as the <get-interface-information> RPC with the <terse/>
> option.  The JUNOS CLI parses either of these into the comand line
> "ifinfo -b".
> 
> We currently are told which commands support XML output and which
> don't.  For those that do, we simply forward the command's output
> to the client.  For those that don't we wrap the output in an XML
> tag that means "we don't support this in XML yet, but here's the
> text" (and escape the data).

Is it possible to introduce a "xo" command which takes a command
line as an argument (in the same way as e.g. "time").  A sample
usage could be "xo ls -s", which should invoke "ls -l" with its
output converted to XML (and "xo -json ls -l" could produce JSON
output).


This command is meant to decouple the request for XO support from
the method that checks for XO support and enables it.

If "xo" determines, that "ls" cannot produce structured output,
it executes it as a sub-command and wraps the output in the way
you describe.  This may not be parseable by a following command
in a pipe, and you could add an "-f" option to "xo" that checks
for XO support and makes the command fail if it is not supported
(instead of wrapping up the result).


The downside is the extra process invocation required for "xo",
but you could use any of the suggested methods to check for and
enable support of XO in programs, and you could change that method
at a later time without breaking existing scripts.


Methods discussed so far are e.g.:

- add long option as ARGV[1] (e.g. "--libxo-is-supported")

- use command name prefix ("xo-$CMD" linked to the actual $CMD)

- test for and use different standard file descriptors (XO_STDIN,
  XO_STDOUT, and XO_STDERR) if supported by the command

(I have probably forgotten a few ...)


If you go for "xo [options] cmd", any of the above mechanisms can
be used and the actual method can be changed at a later time.

And further options (e.g. to control the output format - XML vs. JSON,
for example) could also be passed by any method (e.g via an environment
variable checked by libxo).


Anyway: While the command syntax is not important, it should be
stable.  And that's what an "xo" command could provide ...

Regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F1A311.4080707>