On 19 November 2014 11:56, Richard Elling <[email protected]> wrote: > On Nov 19, 2014, at 11:42 AM, Yacine Kheddache <[email protected]> > wrote: >> I really do not understand why you guys would like to change this (I mean >> between standard output and json output) ? >> Cause today everybody is parsing standard output which mean you are already >> using "-p" arg to display used info in bytes... correct ?
The combination of the "-H" and "-p" flags is currently the most reliable way to get something parseable out of zfs(1M). But these are basically bolt-on flags, added to bend the human-readable output of operator tools into something slightly more useful for programmatic consumption. Adding JSON support to the tooling is a great idea, precisely because it allows us to specify (and commit to supporting) a well-defined output format where programmatic consumption is the primary goal. This format should consist of the best machine-readable representation of the data that we can provide. We should be able to publish a specification document that precisely describes the parts of the format that we are committing to, so that engineers can reliably consume this output in their own code. For example, here is a basic specification for an unrelated JSON-based format: http://eng.joyent.com/usage/format_hf4.html Note that it precisely describes the physical structure of the data (Line-delimited JSON), the names of the keys that we are committing to provide and the data type and structure of each value. Going one step further, we could also provide a JSON Schema[1], akin to an XML Document Type Definition. The output of zfs(1M) could then be validated mechanically against this schema in test suites, to ensure that we don't break the committed output format. [1] http://tools.ietf.org/html/draft-zyp-json-schema-03 >> So why you can not simply use "-p" with "-J" instead of creating (which is >> my main point here in fact) a diff between standard output >> and json output ? In addition is also mean with your suggestion that when >> using "-J" no one can use the human readable output anymore if they want... > Correct, the JSON is consumed by automation, not humans Right. The JSON output format should be rigidly defined, as much as possible. The combination of flags used to produce the JSON data should not have to be a consideration when consuming it. This enables engineers to consume it reliably in software that needs to run across all of the platforms that support OpenZFS, well into the future. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
