On Nov 19, 2014, at 11:42 AM, Yacine Kheddache <yacine.khedda...@alyseo.com>
wrote:
> On Wed, Nov 19, 2014 at 8:23 PM, Richard Elling
> <richard.ell...@richardelling.com> wrote:
>
> On Nov 19, 2014, at 10:33 AM, Matthew Ahrens <mahr...@delphix.com> wrote:
>
>>
>>
>> On Wed, Nov 19, 2014 at 10:08 AM, Joshua M. Clulow <j...@sysmgr.org> wrote:
>> On 18 November 2014 13:55, Matthew Ahrens <mahr...@delphix.com> wrote:
>> >> This seems a reasonable structure to me, except that I would make the
>> >> keys precisely the same string (case included) as what would be
>> >> specified in the "-o" arguments, rather than using the value that
>> >> would display in the headings for human readable output.
>> > And rather than using the standard property name (e.g. "referenced")? This
>> > seems less standardized to me, but I guess parroting back the way they
>> > specified it (e.g. "RefeR") should be workable as well.
>>
>> Sorry, I meant to convey that it should be both spelt the same, and in
>> the same (i.e. lower) case, as it is in the input to the "-o" option.
>> I was reasonably sure that the "-o" option did not accept mixed- or
>> title-case strings and do "the right thing" with them.
>>
>>
>> Ah, right, sorry about that. So it's just giving them back the column
>> header vs the standard name. i.e. if I do "zfs list -J -o refer" then the
>> output will call the property "refer", and if I do "zfs list -J -o
>> referenced", then the output will call the property "referenced".
>
> Already the case in our implementation, see example in previous reply from
> Francois :
>
> # zfs list -J -o name,used,refer | python -m json.tool
> {
> "cmd": "zfs list -J -o name,used,refer",
> "stdout": [
> {
> "name": "tank_mirror",
> "referenced": "19K",
> "used": "55K"
> },
> {
> "name": "tank_strip",
> "referenced": "19K",
> "used": "56,5K"
> }
> ]
> }
>
> So good for all ?
>>
>> In my opinion, for programmatic use (e.g. -J), the standard (full) property
>> name should always be used ("referenced", not "refer"), and the output
>> should always be in parseable format ("12345", not "12.0K").
>
> agree
> -- richard
>
> 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 ?
Speaking for myself (and Coraid)
No. We're using what is effectively a replacement for the zfs command that also
does
nvlist -> JSON. Once you're in JSON, it isn't human readable, so we have no
need or desire
for pretty printing inside the JSON. Since the pretty printing is not
consistent wrt MB/MiB doing
so can only cause problems.
>
> 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 (unless you consider
developers human :-)
-- richard
>
> Example again based on our current implementation :
> > zfs list -pJ -s used -o used | python -m json.tool
> {
> "cmd": "zfs list",
> "stdout": [
> {
> "used": "56320"
> },
> {
> "used": "57856"
> }
> ]
> }
>
> Regards,
> Yacine
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
