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

[Alfred Perlstein]

Agree with kib. 

Kib, one thing that I just don't understand is the point of even being able to query programs for libxo support. Does it make sense to you?  

Sent from my iPhone

> On Aug 15, 2014, at 1:25 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
>> On Thu, Aug 14, 2014 at 10:04:36AM -0700, Marcel Moolenaar wrote:
>> 
>> On Aug 13, 2014, at 10:26 PM, Konstantin Belousov <kostikbel at gmail.com> wrote:
>>>> 
>>>> 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?
>>> No.
>> 
>> Too extreme.
>> 
>>>> Is FreeBSD using Notes for other information currently?
>>> Yes, the notes are used to communicate the information required by
>>> the dynamic linker to correctly activate the image. The mechanism has
>>> nothing to do with application-specific features, and overloading it for
>>> that purpose is severe and pointless layering violation. Things should
>>> not be done just because they could be done.
>> 
>> Too extreme. Life is a lot more subtle. Standards
>> are as well. There are many examples in the real
>> world where standards are interpreted a little
>> more liberal than others may want to. When such
>> result in (gratuitous) incompatibilities, we all
>> interpret it as bad. But when it adds real value,
>> you tend to find it in the next update of the
>> standard.
> 
> Do you suggest that next revision of ELF standard starts talking
> about app-level features ?
> 
>> 
>>> Using the static tagging for the dynamic application properties is wrong
>>> anyway.  E.g., would you consider the mere fact that the binary is linked
>>> against your library, as the indication that your feature is supported ?
>>> If not, how does it differ from the presence of some additional note ?
>> 
>> If we can eliminate static linking for libxo, than
>> that is definitely easy. Easiest probably. The
>> question becomes: is it acceptable to not support
>> static linking for libxo? Or alternatively, is it
>> acceptable to not be able to check for the feature
>> on a static executable?
> Let me clarify. I do not suggest to use DT_NEEDED for libxo (?) as the
> alternative feature test, either. I consider both the proposed note
> and the presence of dependency on libxo.so as equally wrong ways to
> determine the perceived support for specific output formats. My point
> was that note is essentially same as DT_NEEDED tag, with the same set of
> architectural problems, but it is easier to see them for DT_NEEDED.
> 
> Static binaries is just a detail, and yes, I consider static linking
> as place where we cannot hold an ABI guarantee.  The good example
> was kse libpthread, which broke statically linked threaded binaries.
> 
> My objections against use of ELF could be summarized as following:
> - ELF is a binary standard for image activation and runtime system, not
>  for the app level features.
> 
> - Attempt to shoe-horn the discussed feature into binary format makes
>  the indicator cut of the actual feature.  It is like the mark on the
>  plastic can, which may have no relation to the can content.  From
>  this PoV, the options or special env variables are at the right
>  place.
> 
> - It is unportable.  Why bind the pure data transformation library to
>  the platform ?  What about Mach-O or COFF/PE platforms ?  What if
>  FreeBSD decide to change binary format, or add support for a new
>  format, besides ELF ?  What if the tool and consumer are of different
>  ABI ?  E.g., one is 64 bit, another is 32bit.  Usually, there is
>  support for less bits, but 32bit libelf or debugger or libunwind
>  or whatever usually have troubles reading 64bit ELF objects.
> 
>> 
>> For the first I'm inclined to say yes, but not for
>> the second.
> 
> In fact, since I already started talking on the subject, I
> dislike the idea of adding the other text formats to existing
> tools. Much more reasonable route, IMO, is to have a library to
> interrogate system state and present the data in ABI-stable and
> introspection-friendly way, without enforcing the
> 
> kernel->internal userspace structure->text serialization->
>    text parsing ->some other internal userspace structure
> 
> path on the consumers.
> 
> If so inclined, some existing tools could be converted to use the
> library and possibly libxo.  But I suspect that the presence of the
> library for system state and bindings for the most popular scripting
> languages (which is facilitated by the introspection facilities,
> to avoid the need of translating each ABI structure into each language
> datatype) is the sweet spot for the current consumers of libxo
> formatted output.  There would be no need for running external tool,
> determining if it is suitable, parsing its output, treat the text
> output as ABI contract and so on.