From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 06:54:25 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5078738; Mon, 18 Aug 2014 06:54:25 +0000 (UTC) Received: from mailout05.t-online.de (mailout05.t-online.de [194.25.134.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39AFF3276; Mon, 18 Aug 2014 06:54:25 +0000 (UTC) Received: from fwd33.aul.t-online.de (fwd33.aul.t-online.de [172.20.27.144]) by mailout05.t-online.de (Postfix) with SMTP id C59C046F5AD; Mon, 18 Aug 2014 08:54:16 +0200 (CEST) Received: from [192.168.119.33] (XRes1UZOYhfIVQzekWzmQNycC9jB7ZSj-I3wVmnK-xvkQbjr-ke7bYQq8f8AFS0gWg@[84.154.101.219]) by fwd33.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XJGpY-1anVSa0; Mon, 18 Aug 2014 08:54:12 +0200 Message-ID: <53F1A311.4080707@freebsd.org> Date: Mon, 18 Aug 2014 08:54:09 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Phil Shafer , Alfred Perlstein 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 Content-Transfer-Encoding: 7bit X-ID: XRes1UZOYhfIVQzekWzmQNycC9jB7ZSj-I3wVmnK-xvkQbjr-ke7bYQq8f8AFS0gWg X-TOI-MSGID: 3b53171b-f196-43fa-9020-dc778cab534f 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: Mon, 18 Aug 2014 06:54:25 -0000 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 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). 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