Skip site navigation (1)Skip section navigation (2)
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>