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>