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

[Warner Losh]

Sorry for top posting, this really isn’t responsive to the minutia in the rest of the thread.

I’m curious. Why isn’t this conversation about “foo —supports-xml” ? Why tag these commands with weird, non-standard things that need more exotic tools to dig the information out. Why not have a standardized command line option that prints nothing and returns 0 for success, or whines and returns 1 for failure? That’s way more standardized than adding obscure notes that may or may not be allowed by the standard, but that we traditionally haven’t done, which requires tools that aren’t standardized and whose interface varies from one tool to the next. This is true of asking about DT_NEEDED (which forces a specific library for the implementation) as well as anything placed in the NOTES section. It also assumes that you know the thing you are querying is an ELF executable, that you can find it, that there’s not a shell script wrapper for that tool that redirects to binaries that do support this, etc, etc etc.

Basically, what does this ‘meta data’ really buy you that can’t be bought some other, more standard, more direct way that doesn’t enshrine so many hard-coded implementation decisions into the mix?

Warner


On Aug 14, 2014, at 9:16 AM, Phil Shafer <phil at juniper.net> wrote:

> Konstantin Belousov writes:
>> 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 ?
> 
> This would clearly not make sense.  Some meta-data should be
> in the file and some in the filesystem.  Implementing the
> SF_SNAPSHOT file as a note section would be silly.  But
> that doesn't imply that using a note section to facilitate
> proper construction of the environment for running a binary
> isn't reasonable.
> 
>> 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 ?
> 
> Apologies; here is your original question:
> 
>>> 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 ?
> 
> No, I'm not looking for something more explicit than a reference
> to a function in a library.  I'm looking for an explicit marker
> that a binary supports working in a particular environment.  That
> marker could be applied by having the developer link against a
> specific marking library, or by having a tool make the binary
> appropriately.  But it should be something explicit.
> 
> Re: DT_NEEDED: this section holds symbols for dynamic linking.  It's
> content and meaning are explicitly given in the spec.  The note
> section is intended for other generic information.  It seems a
> reasonable place to put the answer to the question "can this binary
> make additional styles of output and how do I trigger that behavior?".
> 
>> Definitely, I do not see an addition of the fashion-of-the-day
>> text-mangling output shattering enough to justify imposing the
>> architecture violation.
> 
> It's partially opinion and perspective, but I don't see an architecture
> violation; I see the use of a generic mechanism to carry relevant
> information.  And I see this addition as a modernization that allows
> better integration with fashionable tools like browsers and
> client/server architectures.
> 
> Thanks,
> Phil
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"

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