From owner-freebsd-current@FreeBSD.ORG Sun Mar 1 19:49:29 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78B45A2F for ; Sun, 1 Mar 2015 19:49:29 +0000 (UTC) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3095ABD9 for ; Sun, 1 Mar 2015 19:49:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 8E138E1B4 for ; Sun, 1 Mar 2015 14:49:24 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.145, BAYES_00=-2.599, DNS_FROM_AHBL_RHSBL=0.692] Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98MWP9h8HNP8 for ; Sun, 1 Mar 2015 14:49:24 -0500 (EST) Received: from bsddt1241.lv01.astrodoggroup.com (unknown [40.141.24.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 34292E0E1 for ; Sun, 1 Mar 2015 14:49:24 -0500 (EST) Message-ID: <54F36CA9.6090108@astrodoggroup.com> Date: Sun, 01 Mar 2015 11:46:49 -0800 From: Harrison Grundy User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Massive libxo-zation that breaks everything References: <54F31510.7050607@hot.ee> <54F34B6E.2040809@astrodoggroup.com> <54F35F29.4000603@astrodoggroup.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 01 Mar 2015 20:17:17 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 19:49:29 -0000 On 03/01/15 11:11, David Chisnall wrote: > On 1 Mar 2015, at 18:49, Harrison Grundy > wrote: >> >> That does seem useful, but I'm not sure I see the reasoning >> behind putting into base, over a port or package, since >> processing XML in base is a pain, and it can't serve up JSON or >> HTML without additional utilities anyway. > > How would it be in a port? It involves modifying core utilities > (some of which, like ifconfig, rely on kernel APIs that change > between releases) to emit structured output. Maintaining two > copies of each utility, one in the base system with plain-text > output only and another in ports with XML/JSON output would be very > painful. > > The goal of having machine-readable output in the base system is > that people building systems atop FreeBSD will be able to expect a > stable, machine-parsable, extensible, output from these tools. If > you're building a web admin GUI or automated administration tool > for FreeBSD 11, or improving integration in your favourite DE, then > you should be able to rely on the output from base system tools, > without having to depend on anything external. > > My only concern with libxo at present is that many of the modified > tools are not emitting self-describing output (e.g. not specifying > units for things), but that's something that we have a year to > shake out before 11. > > David Thinking about the kernel interfaces, I can see the need for it in base... but then it boils down to why, say, ifconfig in particular needs to support this behavior. It seems easier/safer to implement this independently of the existent commands using the various APIs. By putting this in the actual base utilities, an API that I would assume needs to remain relatively static is being introduced that may have some fairly large consequences for how those utilities need to operate. It just seems odd to me to have the same command one would use to, say, join a wireless network and set an IP also spit out HTML reports on interfaces. It seems like the needs of those programs may diverge over time, or that functionality needed for some new ifconfig thing would then require picking (and being stuck with) an XML schema for that information at the same time. --- Harrison