Date: Fri, 15 Aug 2014 12:13:22 -0400 From: Phil Shafer <phil@juniper.net> To: 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: <201408151613.s7FGDMmt003567@idle.juniper.net> In-Reply-To: <3D4EDA4C-6D60-4D05-A1BD-44121EF020B5@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
The benefit of this intrastructure is that clients can parse and
digest the data easier in XML, and can perform scripts like:
for $if in ($res/interfaces/interface[starts-with(name, "xe-")]) {
if ($if/gigether-options/loopback) {
call warning($if, "interface is in loopback mode");
}
}
libxo will add a third class where we set LIBXO_OPTIONS to trigger
XML output (and hopefully eliminate the first one, where we are
currently using the "-X" option to tell commands to make XML output).
I can also imagine a similar server scenario for the restful server
using JSON. Personally, I'm not a fan of JSON, but it's popular
enough to make it a required output style, given that all styles
are generated by the same xo_emit calls.
In the more science fiction work, I can imagine using the HTML
output as a means to escape the 70's era tty world, running a
webkit-enabled shell that can trigger HTML output for libxo-enabled
binaries and decorate the output with custom HTML5 constructs.
My theory is that keyboards are reasonable input devices, but ttys
are poor output devices. With JUNOS, we have a CLI that runs over
tty/ssh/etc and gives command line access to the device. We have
on-box scripting for extensibility, but are hindered by the lack
of features in display output. I tried a number of times to make
a decent looking ascii sparkline before giving up.
If I can marry the high-bandwidth input capabilities of the input
with the high-capacity output of the HTML5 world, I can have a world
where I can combine the flexibility and power that keep me in the
tty world with the direct manipulation and display technology that
makes the HTML5 world appealing.
So a shell that understands that some commands can generate HTML,
notices when they are the last member of a pipeline, and knows to
trigger them to make HTML is a useful first step. (Well, actually
the first step will likely be a "shell in a browser window" sort
of thing, but....)
In any case, the first round of any of these technologies can get
by initially with explicit knowledge of what does or does support
libxo. If/when this actually works, we can revisit it.
Thanks,
Phil
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408151613.s7FGDMmt003567>