From owner-freebsd-current@FreeBSD.ORG Mon Mar 2 20:03:14 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 3019B4A9 for ; Mon, 2 Mar 2015 20:03:14 +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 BD544DB7 for ; Mon, 2 Mar 2015 20:03:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 0D401E3C2 for ; Mon, 2 Mar 2015 15:03:05 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-0.143, 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 KDmgwxjd1h4V for ; Mon, 2 Mar 2015 15:03:04 -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 A30C0E37C for ; Mon, 2 Mar 2015 15:03:04 -0500 (EST) Message-ID: <54F4C127.5020000@astrodoggroup.com> Date: Mon, 02 Mar 2015 11:59:35 -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> <54F429EF.5050400@freebsd.org> <54F46536.8040607@mu.org> <54F4C03F.7030704@freebsd.org> In-Reply-To: <54F4C03F.7030704@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 02 Mar 2015 21:08:30 +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: Mon, 02 Mar 2015 20:03:14 -0000 On 03/02/15 11:55, Julian Elischer wrote: > On 3/2/15 5:27 AM, Alfred Perlstein wrote: >> >> >> On 3/2/15 4:14 AM, Julian Elischer wrote: >>> On 3/1/15 10:49 AM, Harrison Grundy wrote: >>>> Thanks! >>>> >>>> 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. >>>> >>>> (If I'm reviving a long-settled thing, let me know and I'll drop it. >>>> I'm >>>> trying to understand the use case for this.) >>> >>> To me it would almost seem more useful to have a programmable filter >>> for which you could produce >>> parse grammars to parse the output of various programs.. >>> thus >>> >>> ifconfig -a | xmlize -g ifconfig | your-favourite-xml-parser >>> with a set of grammars in /usr/share/xmlize/ >>> then we could use it for out-of-tree programs as well if we wrote >>> grammars for them.. >>> >>> The sentiment of machine-readable output is nice, but I think it's >>> slightly off target. >>> we shouldn't have to change all out utilities, and it isn't going to >>> help at all with 3rd party apps, >>> e.g. samba stuff. A generally easy to program output grammar parser >>> would be truely useful. >>> and not just for FreeBSD. >>> >>> I've been watching with an uncomfortable feeling, but it's taken me a >>> while to put my >>> finger on what it was.. >>> >>> >> Are you sure it's not the hairs on the back of your neck standing up >> due to NIH? >> >> Juniper has been doing this for years and it's very useful for them. > I'm not saying the ability to generate machine readable output is wrong, > but that the 'unix way' would be to make a filter for it. It seems that > the noisy people don't > agree with me so I will not stand in the way of progress.. > Julian and Alfred, Does the "lib-ification" idea address your differing concerns? The idea is to split base binaries into a library that does the "work", and a binary that does the UI bits. This way, "df" becomes a CLI interface connected to "libdf" that handles the CLI output. "xodf" (or whatever we'd like to name it) becomes a libxo interface on top of libdf. This allows the CLI code to remain largely unchanged, and permits the XML output code to link across multiple utilities at the same time. (So that things like, say, ifconfig information can be incorporated into route and netstat results by linking to "libifconfig" "libroute" and "libnetstat", respectively. If we're going to have to touch every base binary anyway, it seems like this might be a useful abstraction to get at the same time. --- Harrison