Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 May 2014 02:15:21 -0700
From:      Alfred Perlstein <bright@mu.org>
To:        freebsd-hackers@freebsd.org
Subject:   Re: [GSoC] Machine readable output from userland utilities
Message-ID:  <537F11A9.8020504@mu.org>
In-Reply-To: <537F0DD9.6090805@highsecure.ru>
References:  <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru>

next in thread | previous in thread | raw e-mail | index | archive | help

On 5/23/14, 1:59 AM, Vsevolod Stakhov wrote:
> On 20/05/14 17:59, Zaro Korchev wrote:
>> I'm working on the project "Machine readable output from userland
>> utilities" and I want to share my ideas and thoughts.
>>
>> Here is the wiki page of the project:
>> https://wiki.freebsd.org/SummerOfCode2014/MachineReadableFromUserlandUtils
>>
>>   I'm planning to create a unified output abstraction in the form of a
>> library. The tools supporting the machine-readable output feature
>> will write output exclusively using the library. The exact output
>> format will be customizable. Several backend libraries (like libucl
>> and libnv) can be used to implement different formats. Such library
>> can either be compiled statically into each application or linked
>> dynamically (depending on space/performance/versioning and other
>> considerations). Each tool will have to be modified to support the
>> new output mechanism. These modifications could trivially be turned
>> on and off using a macro switch. One issue that must be considered is
>> how to manage long outputs since it may not be possible to store all
>> data in memory. This would happen rarely but can still be a problem.
>> Probably the easiest way to solve this is to add streamed dumping
>> capability into the underlying libraries.
>>
>> Do you have any suggestions or ideas?
> For libucl output I've used the following approach:
> - convert all output objects to ucl;
> - write custom emitter for human-readable output.
>
> Perhaps, it might be possible to do it in some unified way, then it is
> worth to think about output to:
>
> 1) some unified BSD/Posix compatible human readable output
> 2) libnv output (I'm not sure about arrays, however)
> 3) xml output (if someone needs it)
>

This is all very interesting.  One point to note is that the intent is 
to have an output that is very consumable by modern scripting languages 
and modules.  That would very likely be JSON output.

-Alfred




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?537F11A9.8020504>