Date: Mon, 2 Jun 2014 14:31:11 +0100 From: David Chisnall <theraven@theravensnest.org> To: Zaro Korchev <zkorchev@mail.bg> Cc: soc-status@freebsd.org Subject: Re: [Machine readable output from userland utilities] report Message-ID: <0FCB749A-67F7-4C2F-AAC1-32D0BD67B502@theravensnest.org> In-Reply-To: <1AE4C0BE-546E-4B02-9664-F460F948794F@mail.bg> References: <8D1B686D-1AAA-4E07-9270-E42699110561@mail.bg> <1AE4C0BE-546E-4B02-9664-F460F948794F@mail.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2 Jun 2014, at 12:43, Zaro Korchev <zkorchev@mail.bg> wrote: > At the moment both ls and vmstat are told to output JSON by specifying = the -O option. However as I discussed with my mentor, this will be = changed. The idea is to use an environment variable instead of the -O = flag. I don't like the idea of using an environment variable, because this is = something that you might want to control on a per-command basis within a = pipeline. Especially with respect to incremental adoption, if you have = some commands that will emit their default format, which is sent to sed = / awk whatever, and some that will emit json natively, you don't want to = suddenly have the output format from the legacy tools change once they = gain machine-readable output support. One *very* important thing to do is standardise the command-line flag = that is used to specify the output format. This may involve also = converting some of the tools to use getopt_long if they don't already = (lots of tools already use most single-digit options, so there's no = possibility to define a single-letter flag that will be useable on all = tools). =20 > I understand your concerns about multi-threading. The idea is to have = functions that serialize the object in an allocated buffer as it is = constructed. Here is a more detailed example of what I mean: It would be better to has some stream output API as the default. If one = back end only supports writing to buffers, then you can add an extra = alloc / write / free sequence to hide it, but it would be good if the = interface understands writing directly to file descriptors. If the back = end natively supports streaming, then you don't need to buffer the = output. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0FCB749A-67F7-4C2F-AAC1-32D0BD67B502>