From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:27:07 2014 Return-Path: Delivered-To: freebsd-hackers@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 61F0CE44 for ; Fri, 23 May 2014 13:27:07 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 330732CAE; Fri, 23 May 2014 13:27:07 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4NDR5Fi047977; Fri, 23 May 2014 13:27:06 GMT (envelope-from jonathan.robert.anderson@gmail.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Jonathan Anderson In-Reply-To: Date: Fri, 23 May 2014 10:57:06 -0230 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> To: Wojciech Puchar X-Mailer: Apple Mail (2.1878.2) X-Mailman-Approved-At: Sat, 24 May 2014 18:30:52 +0000 Cc: freebsd-hackers@freebsd.org, Zaro Korchev X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:27:07 -0000 On 23 May 2014, at 10:13, Wojciech Puchar = wrote: > ideas completely against unix simplicity. I disagree quite vigorously. this proposal is very much like FreeBSD's = sysctl vs Linux's sysfs. It might be against the Plan 9 way of doing = things, but it would actually let us be "more unix than unix". Imagine: $ ifconfig | filterBy "ether" " 3c:07:.*" | sortBy "ether" | output = my_ifconfig.format # or "json" or "xml" or ... A pipeline of little tools, each doing one thing well: how much more = unix can you get? Currently, every command-line tool has to do two or = three things: 1. its primary job, 2. output some arbitrary text format (that you're never allowed to = change because other tools scrape it) and 3. (optionally) parse arbitrary text formats generated by users or some = other tool. Task 2 is annoying: in order to usefully query command-line tools, I = have to write a parser. The tool has binary data, I want binary data, = but we have to go through a dump/parse dance in order for me to get the = data. This is the approach (again, from Plan 9) that brings you Linux = sysfs. Perhaps David would now like to comment on his cross-platform = "how much battery do I have" experience. :) Task 3 isn't just annoying, however, it's risky. If every tool = implements its own string protocol parsing, we greatly increase the risk = of unnoticed bugs. Better to centralize as much string parsing as = possible into a single library, which can be rigorously analyzed (and = optimized!). Imagine if geom didn't have to speak XML natively, but rather used a = supported-everywhere-in-base data structure that users could convert = into XML if they need it. Desktop applications are going to start = requiring structured data passing via kdbus-like interfaces (currently = based on GLib's GVariant), so we might as well have a structured = representation that we like and are able to provide ABI support for = (and, in the kdbus case, can possibly be converted to/from GVariant as = required). Basically, I think this is an excellent GSoC project idea. Jon -- Jonathan Anderson jonathan@FreeBSD.org http://freebsd.org/~jonathan/=