On 2016-05-17 08:23, David Sterba wrote:
On Tue, May 17, 2016 at 07:14:12AM -0400, Austin S. Hemmelgarn wrote:
By this example I don't mean that JSON has to be the format -- in fact
it's a terrible format with all sorts of problems -- any format which
is parseable with C libraries would do for us.
My ideas was to allow multiple formats, with slight change to the
syntax:
$ btrfs --format=json ...
$ btrfs --format=plain ...
$ btrfs --format=yaml ...
I like this idea, with one specific caveat, it would be _really_ nice to
be able to control at compile time what formats are supported.
Somebody's eventually going to want XML support, and I'd rather not have
to depend on expat or something similar in a tool that I regularly build
statically (I'm willing to tolerate YAML because that's what I'd use,
but I would probably compile out the JSON support too).
I hope we can avoid any 3rd party library dependencies, we're just
generating the output not parsing it. Either copy a version of the
libraries or copy the quoting code, the rest can be simply implemented as
a printf with enhanced format stings.
As much as I hate the possibility of having 3rd party library
dependencies in btrfs-progs, I'm a lot more nervous about having the
equivalent stuff open-coded or having a local copy of the library, as
both have significant potential for bugs. A significant majority of
Linux systems have Python, and therefore have at least some XML library
(I forget which one Python prefers to use). Many also have at least one
JSON library too. If we make such dependencies optional, and also only
load the library if we need it at runtime (so we would only load the
JSON library if we are asked to print JSON output), then we could still
avoid the overhead for most people.
The other possibility would be to just pick one output format, open code
that, and be done with it. It's not hard to write s simple script to
convert between YAML, JSON, and other similar formats. If we do go this
way, I'd still suggest YAML as it's more human friendly, a lot easier to
parse using scripts due to the line oriented nature of it, and is also
probably easier to code without any external dependencies.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html