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

[Garance A Drosehn]

On 13 Aug 2014, at 19:02, Marcel Moolenaar wrote:

> On Aug 13, 2014, at 12:36 PM, Phil Shafer <phil at juniper.net> wrote:
>>
>> I've a related topic:  when an app goes to run a child command, how
>> can it determine whether that binary supports libxo-based encoding
>> requests?  This should be known before the binary is run, since
>> there's no means of auto-detecting the supported output after the
>> fact.
>>
>> For example, say I want to make a JSON-based API for my server.  I
>> can setenv("LIBXO_OPTIONS", "json") to get JSON output, but I won't
>> know if the binary supports this or if the output needs to be wrapped
>> and escaped.
>
> Aside:
> Using environment variables can be handy, but isn't always.
> What do you think about calling a libxo init function from
> main() and giving it argc and argv so that libxo options
> are parsed and removed just like what xlib does?

Here are two alternate ideas for controlling the machine-readable
output, in a way where a script can easily tell *if* a command can
generate machine-readable output, and we can provide some set of
common arguments across all commands which do support that output.

1. For each command, the command could check what name it is
   started with.  If the main() routine sees the command was
   started as 'xo-netstat', then it generates machine-readable
   output and supports some extra xo-specific arguments.  It is
   pretty easy to come up with some workable syntax for those
   arguments if the command has a new command name.

2. some shell for launching an xo-aware command.  In this case
   only one command would be added to the system, and you'd
   say 'xocmd netstat ...' instead of 'xo-netstat ...'.  The
   special xo-specific parameters would be specified between
   the 'xocmd' and the standard unix command ('netstat', in
   this example).
   If you're wondering how this could be done:  How about having
   each command looking for a weak-external symbol, and it
   generates the machine-readable output if that loader symbol
   was resolved when the command started up.  Maybe that loader
   could be the entry point for a large chunk of the libxo
   library.  Thus a unix command running without the libxo
   support would be only slightly bigger than it is now.

Please note that in both cases, I am not saying that anyone would
write two separate versions of each unix command.  I'm saying 
there would still be just one set of source files per unix command,
and each unix command would decide which type of output to generate
based on how it was launched.

-- 
Garance Alistair Drosehn                =     drosih at rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA