From owner-freebsd-arch@FreeBSD.ORG Sat Aug 16 00:29:39 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3E42EF2; Sat, 16 Aug 2014 00:29:39 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9317D20C5; Sat, 16 Aug 2014 00:29:39 +0000 (UTC) Received: from u10-2-16-021.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id AF0C7346DDEB; Fri, 15 Aug 2014 17:29:38 -0700 (PDT) Message-ID: <53EEA655.1070009@mu.org> Date: Fri, 15 Aug 2014 17:31:17 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Phil Shafer Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML References: <201408151613.s7FGDMmt003567@idle.juniper.net> In-Reply-To: <201408151613.s7FGDMmt003567@idle.juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , John-Mark Gurney , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , Konstantin Belousov , Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 00:29:39 -0000 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 RPC with the > 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