From owner-freebsd-current@FreeBSD.ORG Tue Mar 3 03:33:39 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 3A4394DD; Tue, 3 Mar 2015 03:33:39 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1831596; Tue, 3 Mar 2015 03:33:38 +0000 (UTC) Received: from [172.20.17.11] (unknown [12.167.51.131]) by elvis.mu.org (Postfix) with ESMTPSA id 522BF341F861; Mon, 2 Mar 2015 19:33:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Massive libxo-zation that breaks everything From: Alfred Perlstein X-Mailer: iPhone Mail (12B440) In-Reply-To: <54F5270D.1010009@freebsd.org> Date: Mon, 2 Mar 2015 19:33:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <54F4FECB.90501@freebsd.org> <197AA5DC-0591-4F71-BF10-51A5D8104C11@mu.org> <54F5270D.1010009@freebsd.org> To: Julian Elischer Cc: Harrison Grundy , "freebsd-current@freebsd.org" 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: Tue, 03 Mar 2015 03:33:39 -0000 > On Mar 2, 2015, at 7:14 PM, Julian Elischer wrote: >=20 >> On 3/2/15 5:30 PM, Alfred Perlstein wrote: >>=20 >>>> On Mar 2, 2015, at 4:22 PM, Andrey Chernov wrote: >>>>=20 >>>>> On 02.03.2015 22:55, Julian Elischer wrote: >>>>> On 3/2/15 5:27 AM, Alfred Perlstein wrote: >>>>>=20 >>>>>=20 >>>>>>> On 3/2/15 4:14 AM, Julian Elischer wrote: >>>>>>> On 3/1/15 10:49 AM, Harrison Grundy wrote: >>>>>>> Thanks! >>>>>>>=20 >>>>>>> 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 b= ase >>>>>>> is a pain, and it can't serve up JSON or HTML without additional >>>>>>> utilities anyway. >>>>>>>=20 >>>>>>> (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 >>>>>>=20 >>>>>> 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.. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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? >>>>>=20 >>>>> 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.. >>> I agree. Even if someone starts with json and xml only, it will need >>> some 3rd format soon, and adding any new format have real possibility to= >>> break all already existent (like adding json+xml breaks plain text in >>> pipes). Moreover, it violates Unix principle 'one tool =3D=3D one genera= l >>> function' and lots of other rules like Eric Raymond ones, making each >>> program looks like systemd. It makes harder to merge changes from other >>> BSDs too. >>> Proper way to do this thing is to back out all changes and write >>> completely separate templates-based parser - xml/json writer. >>=20 >> Read the library. It doesn't care what output format it needs. It is up t= o the translation layer to do it. You could even do a csv format or most any= other structured output format without changing the userland utils. > As far as I can see that's not an argument either way. > I just think it makes more sense to spend more time writing one generic co= nverter and grammar files than to mess up the insides of every utility in th= e system. If we had a tool, we could have grammar templates for 3rd party to= ols easily.. do YOU want to make libxo changes to 3rd party ports? of course= not. so you are going off here solving a half of the problem. Actually I want to shame third party ports into adopting libxo (or at least p= roviding machine readable output).=20 I know it's scary to try to lead the pack, after all we could be wrong, but m= aybe it's time to try something new and see what happens.=20 And no, your idea doesn't make sense it just will lead to those files bit ro= tting. =20 Bedsides that you don't even have a real spec other than "it should be done d= ifferently".=20 Again, show the code.=20