Robert G. Brown
Thu, 25 Sep 2008 17:45:13 -0700
On Thu, 25 Sep 2008, Greg Lindahl wrote:
On Thu, Sep 25, 2008 at 06:34:50PM -0400, Robert G. Brown wrote:So yeah, XML isn't a magic bullet. I think half of the anger people seem to feel for it is because they think it somehow should be.I'm only upset by XML boosters who are so positive about it. You fall into this category; when I began picking nits you admitted that XML has flaws, but until that point, you were preaching its benefits with no mention of its numerous flaws.
One can be enthusiastic about a hammer without thinking all the world is a nail, Greg. And in this particular context I AM enthusiastic about it. Now ask me if I think that we should rewrite PVM or MPI to send all data messages encapsulated in XML...
That's not the point -- the point is that they are easy to PARSE so one can easily write and debug a PARSER (or encoder)So that's why XML parsers are so big and expensive, because it's "easy".
To make it easy for the programmer, sure, compared to rolling your own interface for each application, each with whatever ideas you thought of at the time built into it and different from everybody else's.
Dude, beauty is in the eye of the beholder, or in this case, in the eye of the proud pappa. Your baby is ugly. Your argument of "this is prettier than /proc" is a very weak one. If one person designed /proc it would probably be prettier than your XML. I'll take Don's beostat format sight-unseen over your XML.
Great! Enjoy parsing the variable value 18 bytes from the beginning of the address pointer to get a value, and hope that the API never changes by a byte. That's perfectly fine as well. And I'm not being negative, BTW -- I'm serious, it IS perfectly fine. It has precisely the advantages and disadvantages I outlined before. But -- and this isn't being a proud papa, it is just stating a fact -- you could write a parser for just from the content of my previous email: without a manual, without a library, without a binary-level data dictionary, and inside e.g. perl, or C, or java, or php, without worrying about things like big- or little-endianness. Ugly vs pretty is irrelevant. The data is clearly and cleanly organized, easy to extract and put into structures, capable of dealing with the natural variability of hardware configuration on the sending side -- multiple interfaces, CPUs all handled consistently and automagically, no aggregation or overloading because they suddenly invented dual or quad CPUs. rgb -- Robert G. Brown Phone(cell): 1-919-280-8443 Duke University Physics Dept, Box 90305 Durham, N.C. 27708-0305 Web: http://www.phy.duke.edu/~rgb Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977 _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf