XML Output: libxo - provide single API to output TXT, XML, JSON and HTML

[Alfred Perlstein]

On 8/14/14 9:13 AM, Warner Losh wrote:
> On Aug 14, 2014, at 6:47 AM, John Baldwin <jhb at freebsd.org> wrote:
>
>>>> Marking the binary with a libxo-specific note tells the caller that
>>>> the binary is capable of rendering its output in a non-traditional
>>>> style and gives the caller a means of triggering those styles of
>>>> output.  In the libxo-enabled world, I see this as vital information
>>>> the caller needs to initialize the environment in which the command
>>>> will be run.  Isn't this exactly the sort of information ELF targets
>>>> for note sections?
>>> How binary format has any relevance for an application level feature ?
>>> What would you do with the binaries which permissions are 'r-s--x--x',
>>> which is not unexpected for the tools which gather system information
>>> and have to access things like /dev/mem ?
>>>
>>> You removed and did not answered a crusial question, which is a litmus
>>> test for your proposal.  Namely, how presence of the proposed note in
>>> the binary is different from DT_NEEDED tag for your library ?
>> Yes, checking DT_NEEDED for libxo.so is the first thing I thought of as well.
>> It is equivalent to 'ldd foo | grep libxo'.
> Doesn’t work for static binaries, nor for cases where libxo is linked in by a
> library indirectly, nor for when the command is a shell script that may
> invoke a command that supports this output, nor for a python script that
> implements this output, etc.
>
> My question for people advocating this method: Why not require all commands
> that generate this kind of output to support a standard command line option
> that causes the command to print nothing and return 0 if it supports reporting,
> or anything else if it doesn’t (return 0 with output, or return non-zero with or without
> output). This would handle the more complicated implementation issues with using
> DT_NEEDED and/or the ELF note, be more in line with how things are traditionally
> done, and offer greater flexibility of implementation.
>
> Warner
This is a decent idea, however the problem is firstly that most 
short-opts are taken, second issue is that adding getopt_long to a whole 
slew of programs will make the effort take a long time.  It's really 
better to limit scope of this such that we are just making machine 
readable output.

-Alfred