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

[Marcel Moolenaar]

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?

> I know ELF "Note" elements can be used to carry vendor-specific
> data, but have no experience with them.  Would it be reasonable to
> use them as a means of communicating this information to other bits
> of software?  Is FreeBSD using Notes for other information currently?

Notes are used to tag the binary as a FreeBSD one (note is
consumed by the kernel) or in core files for meta data
(consumed by the debugger).

A note section is definitely possible and reasonable.
Especially if it's a note section for listing features. A
special utility that consumes the note section to list
features and returns whether a feature is supported is then
very reasonable because it's generic. libxo would be the
first feature we can check for. The question is: do we have
more features we want to check for this way? If not, then
such a scheme could be perceived as "heavy handed".

Alternatives include looking for a particular symbol or
possibly even running the utility with a libxo option that
has predictable output. The last suggestion has some issues
with handling the behaviour when libxo isn't supported
therefore, a passive way to check seems better than having
to run the utility.

BTW: this is pretty powerful stuff! I feel FreeBSD is
maturing :-)

-- 
Marcel Moolenaar
marcel at xcllnt.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140813/8e92a1b6/attachment.sig>