> If anyone should think that it would be better to attempt to preserve some
> level of backwards compatibility on the collector.data attribute, let me
> know.

I don't think it is a big deal. The script_handler collector not only
uses a StringIO as its data, but it also reverses the order of the
arguments in its call to handler.continue_request(), so it seems
evident that there was not a lot of expectation that anyone would be
subclassing the collector or even using it apart from its handler.
That being the case, it seems reasonable that a QuixoteHandler should
have its own Collector, too.

After seeing your initial heads-up on the use of string concatenation
in the xmlrpc_handler.collector, I wrote my own "QCollector" which
uses StringIO for its data but otherwise looks just like the xmlrpc
one, so your Collector patch, which is the same thing except for using
list.join instead of StringIO, seems just fine to me.

Jim Dukarm
DELTA-X RESEARCH
Victoria BC Canada