[GSoC] Machine readable output from userland utilities

[Alfred Perlstein]

On 5/21/14, 12:17 AM, Royce Williams wrote:
> On Tue, May 20, 2014 at 10:17 PM, Erik Cederstrand
> <erik+lists at cederstrand.dk> wrote:
>>
>> Den 21/05/2014 kl. 06.20 skrev Alfred Perlstein <bright at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>