XML for formatting (Re: Environment monitoring)

Mark Hahn hahn at physics.mcmaster.ca
Tue Oct 14 18:13:53 EDT 2003


> > <?xml version="1.0"?>
> > <sensors>
> >   <cpu_temperature id="0" units="C">54.2</cpu_temperature>
> 
> You know... one problem I see with this, assuming this information is
> going to pass across the net (or did I miss something).  Is that instead
> of passing something like four bytes (ie "54.2"), you are going to be
> passing 56 bytes (just counting the cpu_temp line).  So the XML blows up
> a little bit of data 14 times.  I can't see this being particularly
> efficient way of using a network.  Sure, it looks pretty, but seems like
> a waste of bandwidth.  

I'm sure some would claim that 56 bytes is not measurable overhead,
especially considering the size of tcp/eth/etc headers.  but it's 
damn ugly, to be sure.  this sort of thing has been discussed several
times on the linux-kernel list as well - formatting of /proc entries.

it's clear that some form of human-readability is a good thing.
what's not clear is that it has to be so exceptionally verbose.

think of it this way: lmsensors output for a machine is a record
whose type will not change (very fast, if you insist!).  so why should
all the metadata about the record format, units, etc be sent each time?
suppose you could fetch the fully verbose record once, and then on 
subsequent queries, just get '54.2 56.7 40.1 3650 4150 5.0 3.3 12.0 -12.0'.
the only think you've lost is same-packet-self-description 
(and, incidentally, insensitivity to reordering of elements...)

there *is* actually a very mind-bending binarification procedure for xml.
it seems totally cracked to me, though, since afaikt, it completely tosses 
the self-description aspect, which is almost the main point of xml...
of course, the whole xml thing is a massive fraud, since it does nothing 
at all towards actual interoperability - there must already be thousands
of different xml schemas for "SKU", each better than the last, and therefore
mutually incompatible...

does ASN.1 improve on this situation at all?

regards, mark hahn.

_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list