algorithms with less storage for producing results.xml?

[Allyn Dimock]

I am running into a problem that as more test are added to out regression 
testing system, and as more informational messages are added the size of
the results.qmr file grows it becomes difficult or impossible to produce
a results.xml file because of memory thrashing or hard limits.

Is there an algorithm for reporting that does not require the entire 
results.xml file to be built in memory?

My understanding of the results.xml format is that it is
<report>
   <suite>
   ( <test id="..." /> )*
   </suite>
   <results>
   ( <annotation key="...">
       text
     </annotation> )*
   ( <result id="..." kind="..." outcome="...">
     ( <annotation name="...">
         text
       </annotation> )*
     </result> )*
   </results>
</report>

It looks as if this format could be generated in two passes over
the results.qmt file(s) without requiring much more memory than
the size of an annotation.  One pass to generate the <test /> entries
and a second pass to generate the <result>...</result> entries.
I don't know Python xml generation packages.  How easy / difficult would 
this be to do?

One might say "this is only putting the problem off to the programs 
parsing the results.xml file" but the event-driven xml parsers do not need 
the whole file to extract data.

[ This had not been an issue for us when using qmtest 2.0: the xml report
not being availble at the time, we reverse engineered the results.qmt
format to generate the reports that we wanted in one pass per report (one 
summary report that was e-mailed to developers and detais were in a 
collection of html files referencable from the rt ticket tracker system).
   In 2.3 we started relying on results.xml since the results.qmt format 
had changed from 2.0 and we did not want to reverse engineer multiple 
times when a non-proprietary format was available. ]

I don't have time to hack on this until after a Sep. 1 release of our 
product.  I can try something then for handling large results.qmr files, 
or one of the gurus could try something earlier if so inclined.

Is this high on other qmtest users lists?

-- Allyn

"Allyn Dimock" <dimock at csail.mit.edu>