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>