Date: Fri, 15 Aug 2014 14:45:41 -0400 From: "Garance A Drosehn" <drosih@rpi.edu> To: "Marcel Moolenaar" <marcel@xcllnt.net> Cc: Marcel Moolenaar <marcel@freebsd.org>, Phil Shafer <phil@juniper.net>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net>, arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <C393883C-1612-4C25-B7FD-DD42FF890F93@rpi.edu> In-Reply-To: <613EB1A5-2932-446A-A9A2-8CBDD060A00B@xcllnt.net> References: <201408131936.s7DJaA1r089174@idle.juniper.net> <613EB1A5-2932-446A-A9A2-8CBDD060A00B@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Aug 2014, at 19:02, Marcel Moolenaar wrote:
> On Aug 13, 2014, at 12:36 PM, Phil Shafer <phil@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 =3D drosih@rpi.edu
Senior Systems Programmer or gad@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C393883C-1612-4C25-B7FD-DD42FF890F93>