Back out previous revision that changed the XML output format to RPC
format instead of plain old well formed XML. Note this change does not affect the parser in any way; the parser continues to spit out its own brand of XML, and xmlconvert treats that special when it reads it. The XML I spit out now is better formed and makes more sense when you look at it. It also helps that its much faster to generate, and the resulting output is much smaller. For example: time /usr/testbed/libexec/xmlconvert testbed jail-2440 real 2m54.229s user 1m7.492s sys 1m15.927s time /usr/testbed/devel/stoller/libexec/xmlconvert testbed jail-2440 real 0m14.738s user 0m5.755s sys 0m5.156s /tmp/bar*.xml -rw-rw-r-- 1 stoller wheel 15595161 Jun 4 11:16 /tmp/rpc.xml -rw-rw-r-- 1 stoller wheel 5285690 Jun 4 11:17 /tmp/plain.xml Thats for a big experiment. For a small experiment: time /usr/testbed/libexec/xmlconvert testbed jail-416 real 0m9.346s user 0m5.083s sys 0m2.675s time /usr/testbed/devel/stoller/libexec/xmlconvert testbed jail-416 real 0m2.751s user 0m1.377s sys 0m1.183s ll /tmp/bar*.xml -rw-rw-r-- 1 stoller wheel 3135518 Jun 4 11:19 /tmp/rpc.xml -rw-rw-r-- 1 stoller wheel 1015745 Jun 4 11:19 /tmp/plain.xml As you can see, the RPC code is rather non-linear in its performance! Since this affects Tim and netlab-client, I have added an alternate XMLRPC routine called virtual_topology_xml() that returns the new format, since Tim will need to transition to this new format (parsing it into a Java data structure). The old format is left in the RPC server until that is done.