Date: Thu, 31 Jul 2014 14:16:27 -0400 From: Phil Shafer <phil@juniper.net> To: Garance A Drosehn <drosih@rpi.edu> Cc: arch@freebsd.org, marcel@freebsd.org, "Simon J. Gerraty" <sjg@juniper.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <201407311816.s6VIGR07096191@idle.juniper.net> In-Reply-To: <08B4AE10-1747-4BB1-AA1A-BA4491A57F95@rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosehn writes:
>What if there's something you want to print out for xml/json but
>*not* for plain-text? (it's easy to imagine some commands might
>print out more values when they are not constrained by an 80-char
>width).
The "d" flag instructs libxo so only emit for "display" formats
(TEXT, HTML) and the "e" flag for "encode" formats (XML, JSON).
xo_emit("{d:count}{e:count}", "fourth", "4");
>Also, given that machine-readable outputs might change over time,
>is there the idea of including a version-number with the output
>for each command?
I imagine at some point in the future we could see YANG
models for this output, with revision strings and more.
In practice, this turns out to be a minor issue, if strong
discipline is maintained. Future versions can emit new
tags, but not remove old tags. So a script that uses an
XPath expression like:
user-entry[user == 'phil' && idle/@seconds > 6000]
it should work forever. XML becomes an API, where your API makes
a contract saying "I won't change" and deprecating XML elements
becomes as rare as deprecating functions in libc.
>I hope it doesn't seem like I'm just complaining about the work
>everyone else is doing (both this and the GSOC project). Please
>note that I've attempted to do this a few times myself, and I haven't
>been happy with any of *my* attempts either!
I'm been kicking this idea around in my head for years. The first
XML API in JUNOS was 2001. But the way we do this in JUNOS is not
a good fit for BSD; we emit XML from our daemons and the CLI uses
an output definition language to know how to turn XML into text.
BSD needs point-of-creation content generation flexibility, and
some scheme for the shell/parent to tell the what sort of data
should be generated. I'm using the LIBXO_OPTIONS variable to do
this, so your RESTful API daemon can set this env var, run the
command, and funnel the output back to the client. There needs
to be a mechanism for marking the executable to say which types
of data formats are support, or if libxo is supported at all.
Thanks,
Phil
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201407311816.s6VIGR07096191>