Date: Wed, 21 May 2014 01:29:19 -0700 From: Alfred Perlstein <bright@mu.org> To: Royce Williams <royce@tycho.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: [GSoC] Machine readable output from userland utilities Message-ID: <537C63DF.1090402@mu.org> In-Reply-To: <CA%2BE3k91obr3AVGEme5sVU2NQy0scmeT6beN6E9WUz5a6gUnMbQ@mail.gmail.com> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> <E9594D41-64FE-4957-98FD-4E52BCCB2598@cederstrand.dk> <CA%2BE3k91obr3AVGEme5sVU2NQy0scmeT6beN6E9WUz5a6gUnMbQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/21/14, 12:17 AM, Royce Williams wrote: > On Tue, May 20, 2014 at 10:17 PM, Erik Cederstrand > <erik+lists@cederstrand.dk> wrote: >> >> Den 21/05/2014 kl. 06.20 skrev Alfred Perlstein <bright@mu.org>: >> >>> In all seriousness though, the real target is people writing higher level languages (than shell) on top of FreeBSD. Perhaps python or ruby spawning a utility and then that utility making the output easy to read. >> If that's the use case, than I'm fine with this. I often find I need to combine Python and shell output (working with dates in shell is horrible, for example), and formalized output would simplify some scripts considerably. > +1. > > As part of this, may I suggest structured version and > version-transition metadata for the exported data formats? > > All formalized output should publish current and supported API version > numbers, and deprecation/removal target versions of some kind. Tools > would need to be able to request a specific API version number. This > will allow tools that consume structured output to transition to new > formats in a stable fashion. Scripts can check for deprecated API and > start sounding the alarm in advance. > > For example, if I'm consuming top output, I can ask for "2.0 output", > whereupon top could tell me that 2.0 output will be deprecated as of > 3.0, and no longer supported as of 4.0. > > Today, human-readable and machine-readable are happening at the same > time. More than once, when I've suggested output improvements, I've > gotten the "too many systems are scraping this output for us to change > it" response. This will really lay the groundwork to help with that > ... someday. Worth the effort. This is a great idea. Having compat formats is very important. That said there are a few things here we can do to keep the scope of this project down to something doable by a student as well as very useful for FreeBSD. First off we can decide that without any additional specification that v1.0 is the default version, it then becomes up to the app to ask for v2.0, v2.1, etc at a later date. Second off we can explain to people that the format may actually grow to have more fields and that applications are expected to ignore those additional fields. Doing so means that we only need to rev the output version if there is a field we retire or change the actual machine format of which should be a rare occurrence. -Alfred > > Royce > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?537C63DF.1090402>