>> XML is evil. Well, evil for this.
>> Ganglia does consume a significant portion of resources.
> I've heard first-hand reports of 20% CPU. (Admittedly before
> they figured out what was happening and turned the reporting
> list and frequency way down.)
>> When we found that we needed to support Ganglia, I grumbled
> mightily and set out to figure out why it was so bad. Deep
> in its black heart I found the source of evil: XML. And not
> just the detailed evil of the syntax, the evil power had
> seeped into the higher level architecture with needless
> flexibility.[*1]
>> [*1] Yes, you read that correctly. The 'do anything, in
> multiple ways'
> nature of XML encourages projects to not make the hard design
> decisions up front. Just like on SourceForge when a
> pre-alpha project describes itself as "a framework that aims to..."
I fully agree with Don's comments here. I'm doing something now where folks want to do configuration of radios on spacecraft (a very resource limited environment) using XML as the configuration file. While XML is nice in the sense that it defines a syntax that's readily extensible, it's also pretty unconstrained, and the parsers have a pretty large footprint. (and, originally, they wanted multiple levels of abstraction, full pub/sub middleware, dynamic reconfiguration, etc. This is all quite a chore for a 25 MHz processor and a few tens of KLOCs to do. )
More to the point, that very extensibility means that either the application has to do enormous run-time checking to make sure you're asking for something legal, or you have to artificially constrain what's in the XML (by means of a very complex schema or validator). And, in an environment where you have to write testable requirements for each and every thing, flexibility costs a huge amount. Much better to constrain it a bit. (which is what Don has described..)
Jim