XML Output: libxo - provide single API to output TXT, XML, JSON and HTML
Alfred Perlstein
bright at mu.org
Fri Aug 15 00:39:31 UTC 2014
On 8/14/14 8:23 AM, Warner Losh wrote:
> Sorry for top posting, this really isn’t responsive to the minutia in the rest of the thread.
>
> I’m curious. Why isn’t this conversation about “foo —supports-xml” ? Why tag these commands with weird, non-standard things that need more exotic tools to dig the information out. Why not have a standardized command line option that prints nothing and returns 0 for success, or whines and returns 1 for failure? That’s way more standardized than adding obscure notes that may or may not be allowed by the standard, but that we traditionally haven’t done, which requires tools that aren’t standardized and whose interface varies from one tool to the next. This is true of asking about DT_NEEDED (which forces a specific library for the implementation) as well as anything placed in the NOTES section. It also assumes that you know the thing you are querying is an ELF executable, that you can find it, that there’s not a shell script wrapper for that tool that redirects to binaries that do support this, etc, etc etc.
>
> Basically, what does this ‘meta data’ really buy you that can’t be bought some other, more standard, more direct way that doesn’t enshrine so many hard-coded implementation decisions into the mix?
In addition I am wondering what branding the binaries really offers "as-is".
Example, let's say you have a means to query and find out that "netstat"
supports libxo.
Well, netstat has many output variants:
netstat
netstat -r
netstat -a
netstat -nr
netstat -na
netstat -p tcp
So given that is appears that we want to build something so that "file
browsers" can automatically determine that a program can be run in
"libxo" mode and some form of output should be rendered, what exactly is
the preferred format?
What happens when a particular program's default behavior is to filter
stdin, but yet supports libxo, how is that handled?
What happens when a particular program's default behavior is to run
indefinitely, and yet supports libxo, how is that handled?
It makes sense to limit the scope of the project to just doing the
formatted output at least until we see what we get when get a whole
bunch of tools running with it.
Speaking of getting a whole bunch of tools running with it, the GSOC
project happened to have near a dozen programs converted, how is the
libxo project coming along, do we have more programs converted? Without
the programs converted we don't have very much to show even with a great
library.
What other apps use libxo in the tree now?
-Alfred
More information about the freebsd-arch
mailing list