On Nov 19, 2014, at 12:17 PM, Joshua M. Clulow <j...@sysmgr.org> wrote:
> On 19 November 2014 11:56, Richard Elling > <richard.ell...@richardelling.com> wrote: >> On Nov 19, 2014, at 11:42 AM, Yacine Kheddache <yacine.khedda...@alyseo.com> >> 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 I find orderly to be much easier to use and can automatically generate JSON schema. http://orderly-json.org/ > >>> 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. +1 -- richard > > > Cheers. > > -- > Joshua M. Clulow > UNIX Admin/Developer > http://blog.sysmgr.org
_______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer
