Skip site navigation (1)Skip section navigation (2)
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>