Date: Mon, 26 May 2014 18:30:31 +0100 From: David Chisnall <theraven@theravensnest.org> To: Zaro Korchev <zkorchev@mail.bg> Cc: vsevolod@FreeBSD.org, soc-status@freebsd.org, Eitan Adler <eadler@FreeBSD.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, jonathan@FreeBSD.org Subject: Re: [Machine readable output from userland utilities] report Message-ID: <899129C5-977C-4CE7-A873-460D69D6EA85@theravensnest.org> In-Reply-To: <15BC1D7C-B909-48DB-AB6D-FF0F0F9C2B0A@mail.bg> References: <8D1B686D-1AAA-4E07-9270-E42699110561@mail.bg> <4890861C-FC91-445D-AE9B-31CD5FDFD0A9@theravensnest.org> <15BC1D7C-B909-48DB-AB6D-FF0F0F9C2B0A@mail.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 May 2014, at 15:34, Zaro Korchev <zkorchev@mail.bg> 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. =20 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 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. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?899129C5-977C-4CE7-A873-460D69D6EA85>