From owner-soc-status@FreeBSD.ORG Wed May 28 10:41:23 2014 Return-Path: Delivered-To: soc-status@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 5ABE5437; Wed, 28 May 2014 10:41:23 +0000 (UTC) Received: from h.highsecure.ru (h.highsecure.ru [144.76.31.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAE96274D; Wed, 28 May 2014 10:41:22 +0000 (UTC) Received: from medway.cl.cam.ac.uk (medway.cl.cam.ac.uk [IPv6:2001:630:212:238:21c:c0ff:fe4b:2b85]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by h.highsecure.ru (Postfix) with ESMTPSA id 8ACE0300550; Wed, 28 May 2014 12:40:34 +0200 (CEST) Message-ID: <5385BD49.5020602@FreeBSD.org> Date: Wed, 28 May 2014 11:41:13 +0100 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: David Chisnall , Zaro Korchev Subject: Re: [Machine readable output from userland utilities] report References: <8D1B686D-1AAA-4E07-9270-E42699110561@mail.bg> <4890861C-FC91-445D-AE9B-31CD5FDFD0A9@theravensnest.org> <15BC1D7C-B909-48DB-AB6D-FF0F0F9C2B0A@mail.bg> <899129C5-977C-4CE7-A873-460D69D6EA85@theravensnest.org> In-Reply-To: <899129C5-977C-4CE7-A873-460D69D6EA85@theravensnest.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , soc-status@freebsd.org, Eitan Adler , jonathan@FreeBSD.org X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 10:41:23 -0000 David, Zaro, On 26/05/14 18:30, David Chisnall wrote: > On 26 May 2014, at 15:34, Zaro Korchev wrote: > >> I considered using libucl and libnv. The problem with libucl is >> that it does not support streamed output so, after a discussion >> with my mentors, I decided to implement this prototype version >> using YAJL. This is not a final decision but that's what I'm using >> at the moment. > > That's fine, as long as you're prototyping an interface for an > abstraction layer it doesn't matter much what is on the back end, I > just wanted to make sure that you were thinking about libucl as an > eventual back end. > > I've added Vsevolod to the cc list, as he's the author of libucl - > perhaps he can add the missing functionality that you require. > > I definitely agree that streaming is important - we want to be able > to construct pipes of these, although hopefully the total amount of > data won't be huge. I do not understand what is streaming *output* in case of any serialization format. Does it means that you want to have some output on object changing? This is not currently supported by libucl, but the design of ucl emitter allows to implement it in a rather straightforward way. YAJL, on the contrary, supports JSON only. > >> I may use libnv soon - I just haven't had need for it yet. It has >> one limitation that I'm concerned about - it does not support >> arrays (the only supported composite data type is key, value >> pairs). > > Arrays in libnv came up at BSDCan. Apparently someone (Pawel?) has > patches for arrays, but didn't commit them because there were no > consumers in the base system that needed them. It sounds like you've > just volunteered as a beta tester ;-) > > It would also be good to consider prepending a header to each stream > so that tools can consume them without having to be aware of the > format. JSON has the nice property that it can be spotted quite > easily be examining the first 4 bytes (in any unicode encoding). I'm > not sure if UCL and NV have the same property - if they do, then we > don't need to worry. Libucl itself can produce valid JSON. The pure `UCL` output is mostly a human readable output. -- Vsevolod Stakhov