Date: Fri, 23 May 2014 10:57:06 -0230 From: Jonathan Anderson <jonathan.robert.anderson@gmail.com> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: freebsd-hackers@freebsd.org, Zaro Korchev <zkorchev@mail.bg> Subject: Re: [GSoC] Machine readable output from userland utilities Message-ID: <EE4AB00C-9347-4601-A4A2-7BAC5D5F44A3@gmail.com> In-Reply-To: <alpine.BSF.2.00.1405231442500.24615@wojtek.tensor.gdynia.pl> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <alpine.BSF.2.00.1405231442500.24615@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 May 2014, at 10:13, Wojciech Puchar = <wojtek@wojtek.tensor.gdynia.pl> 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/=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE4AB00C-9347-4601-A4A2-7BAC5D5F44A3>