From owner-soc-status@FreeBSD.ORG Wed May 28 12:06:51 2014 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B20DFBF; Wed, 28 May 2014 12:06:51 +0000 (UTC) Received: from mx1.mail.bg (mx1.mail.bg [IPv6:2001:67c:16b8:1::2:17]) by mx1.freebsd.org (Postfix) with ESMTP id 652A42EAA; Wed, 28 May 2014 12:06:51 +0000 (UTC) Received: from [10.1.1.159] (unknown [95.87.254.225]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.mail.bg (Postfix) with ESMTPSA id 853EA6000E6A; Wed, 28 May 2014 15:06:48 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1401278808; bh=5Nnrr6j3LrE4AeLC9ZSatKWUf4RyZ00zQZW+Bna6hsE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=8a/i12VW4Egf3YCRTpn+Ef+0rOAZ9OzZzQ/RWTvp4M+E6E8ILAVHwFX4Y7wA+ihZ5 2mymJk2dWIGnYWFIatTHETRW2TlNrcDUYihB8ffvY2eTYKwTVBD7hXAYxwYUbjMfcr yXIOHzNlTTMRIdi/8Jxqhaf02/YvWq0jYPH2Jw0o= Subject: Re: [Machine readable output from userland utilities] report Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Zaro Korchev In-Reply-To: <5385BD49.5020602@FreeBSD.org> Date: Wed, 28 May 2014 15:06:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <105B3699-2A41-4384-8D02-523D8445436B@mail.bg> 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> <5385BD49.5020602@FreeBSD.org> To: Vsevolod Stakhov X-Mailer: Apple Mail (2.1283) Cc: Pawel Jakub Dawidek , soc-status@freebsd.org, Eitan Adler , David Chisnall , 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 12:06:51 -0000 Le 28 May 2014 =E0 13:41, Vsevolod Stakhov a =E9crit : > David, Zaro, >=20 > 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? >=20 > This is not currently supported by libucl, but the design of ucl = emitter > allows to implement it in a rather straightforward way. The idea is to serialize the object as it is constructed. That way it is = not necessary to keep all the data in memory at any given moment. This = also allows to create pipeline when the second application starts = consuming output before the first one finished producing it. for example: object_start(buf, ...) writes to buf: { object_key(buf, ..., "foo") writes to buf: "foo" sol_object_integer(buf, ..., 42) writes to buf: : 42 sol_object_end(buf, ...) writes to buf: } I hope this explains the idea clearly :) >=20 > YAJL, on the contrary, supports JSON only. Yes, YAJL is limited to JSON. I'm currently using it but I can switch to = using another library easily without changing too much code. If I can = use libucl in the way similar to what I've descibed above, that will = ease supporting multiple output formats. I'm in no way in a hurry for this. Supporting formats other than JSON is = not urgent. Thank you, Zaro