Date: Fri, 15 Aug 2014 17:31:17 -0700 From: Alfred Perlstein <bright@mu.org> To: Phil Shafer <phil@juniper.net> 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: <53EEA655.1070009@mu.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
Phil, thank you for explaining, comments inline.
On 8/15/14 9:13 AM, Phil Shafer wrote:
> 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).
OK, this is making sense now. It really is to "run any command" in
almost a file browser sort of manner. Almost like OS X ".app"
directories or embedding the Windows icon inside of a .exe.
>
> 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.
JSON would be huge, every time I mention that FreeBSD is about to grow
this support the eyes of webapp developers and devops people light up
with joy.
>
> 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.
>
Thank you, this makes a lot of sense now.
I do think that maybe we ought to do a first pass with a mind for just
support of the output formats and get as many utils moved over asap as
opposed to wrapping this up in a larger architectural movement.
Just FYI, using ELF notes does cause issues for scripts, unless perhaps
those scripts have another way to signify that they will produce
"xo-like" output.
I'm just nervous that this might not get done because we get into deeper
issues like the ELF sections as opposed to just making a good idea
happen (libxo itself.).
-Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53EEA655.1070009>