From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 09:15:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B95EBE0 for ; Fri, 23 May 2014 09:15:25 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A78E02535 for ; Fri, 23 May 2014 09:15:25 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 5B7841A3C7D for ; Fri, 23 May 2014 02:15:19 -0700 (PDT) Message-ID: <537F11A9.8020504@mu.org> Date: Fri, 23 May 2014 02:15:21 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> In-Reply-To: <537F0DD9.6090805@highsecure.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 09:15:25 -0000 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