What's coming in glibc 2.10: XML

Posted Apr 19, 2009 16:19 UTC (Sun) by bvdm (guest, #42755)
In reply to: What's coming in glibc 2.10: XML by jkohen
Parent article: What's coming in glibc 2.10

Using XML for this purpose is really not that unreasonable given that very few applications will call this function and they likely already have an XML parser as dependency.

Besides, if you want to export information in a standard and extensible manner, XML is pretty much the way to go. Now Protocol Buffers, that would be over-engineering!

What's coming in glibc 2.10: XML

Posted Apr 19, 2009 21:51 UTC (Sun) by elanthis (guest, #6227) [Link] (2 responses)

It's very unreasonable, because it's a HUGE freaking specification and there's no truly compelling reason not to use a simple list of structs with a corresponding free_mallocinfo() function, just like any number of similar APIs in the libc already use.

What's coming in glibc 2.10: XML

Posted Apr 20, 2009 10:43 UTC (Mon) by alankila (guest, #47141) [Link] (1 responses)

Don't overlook the possibility that this decision is a harbinger for using less binary structs in glibc's API, and more XML. Could happen.

I think it's quite safe to assume that Ulrich means "text with angle brackets" rather than the entirety of XML specification. In other words, even a crude parser is likely to work...

What's coming in glibc 2.10: XML

Posted Apr 20, 2009 15:07 UTC (Mon) by drag (guest, #31333) [Link]

Well ya.. XML is simple. Angle-y brackets and a few other small things then your done.

I don't know why people are getting excited about this. Mallocinfo seems to me to be a very poorly designed part of the POSIX spec and, like the blog entry said, is dependent on the specifics of a particular malloc implimentation.

The particular Mallocinfo in the spec is so widly useless for any sort of modern system that there is just no 'right' way to do it.

So since it's returning statistica data that are dependent on a particular internal inplimentation then the sort of statistics that are relevent to anybody are going to change based on the changes of Malloc.

So instead of requiring application designers to use some sort of custom parser or try to read data whose relevence and meaning, at any point in the future, can and will change he has decided to go with a very commonly used, standard, self-describing format... which is XML.

Makes sense to me.

Who is going to read this information anyway?

Posted Apr 20, 2009 0:27 UTC (Mon) by xoddam (guest, #2322) [Link] (1 responses)

Heap implementation and performance details are not the sort of thing an application can hope to comprehend and adapt to on the fly. I would expect this information to be examined only by developers (often after the fact eg. in logs depicting memory pressure in a production system experiencing performance problems or horrible OOM events), who might prefer a more human-readable representation but shouldn't be afraid of XML in the case of a complex hierarchical heap structure.

Who is going to read this information anyway?

Posted Apr 20, 2009 19:41 UTC (Mon) by jkohen (subscriber, #47486) [Link]

In this case there is really no excuse to go with XML. Even something like /proc/meminfo is more readable to a human than structured markup.

If you want structured data ready for human consumption, you probably need to write a user-space tool, in which case using XML is no better than protocol buffers, JSON and so on; it just has a more complicated spec.