From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 16:13:49 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 DEB57874; Fri, 15 Aug 2014 16:13:49 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CDA8254F; Fri, 15 Aug 2014 16:13:48 +0000 (UTC) Received: from BY2PR05CA062.namprd05.prod.outlook.com (10.141.250.52) by CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 15 Aug 2014 16:13:46 +0000 Received: from BN1AFFO11FD029.protection.gbl (2a01:111:f400:7c10::146) by BY2PR05CA062.outlook.office365.com (2a01:111:e400:2c5f::52) with Microsoft SMTP Server (TLS) id 15.0.1010.18 via Frontend Transport; Fri, 15 Aug 2014 16:13:45 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BN1AFFO11FD029.mail.protection.outlook.com (10.58.52.184) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Fri, 15 Aug 2014 16:13:45 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 15 Aug 2014 09:13:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s7FGDWn17204; Fri, 15 Aug 2014 09:13:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id s7FGDMmt003567; Fri, 15 Aug 2014 12:13:22 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201408151613.s7FGDMmt003567@idle.juniper.net> To: Alfred Perlstein Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-Reply-To: <3D4EDA4C-6D60-4D05-A1BD-44121EF020B5@mu.org> Date: Fri, 15 Aug 2014 12:13:22 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(189002)(199003)(164054003)(20776003)(21056001)(68736004)(46102001)(95666004)(47776003)(64706001)(110136001)(50466002)(74662001)(99396002)(85852003)(105596002)(54356999)(53416004)(87936001)(103666002)(107046002)(81542001)(106466001)(81156004)(102836001)(86362001)(77982001)(81342001)(69596002)(76506005)(84676001)(4396001)(44976005)(31966008)(48376002)(6806004)(92566001)(79102001)(50986999)(76482001)(80022001)(97736001)(85306004)(83072002)(74502001)(92726001)(83322001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB731; H:P-EMF01-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0304E36CA3 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=phil@juniper.net; X-OriginatorOrg: juniper.net 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: Fri, 15 Aug 2014 16:13:50 -0000 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). 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