----- Original Message ----- From: "Daniel Rall" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 18, 2002 11:10 PM Subject: Re: XmlRpcServer found un-streamy
[snip] > > 1. It might be reasonable to perform two passes over the result > > object, one to compute the content length, and then one to stream it > > out. > > The value of this change would depend heavily on how long it takes to > create the response, and just doesn't seem very elegant (though > neither does a frozen XML-RPC spec, bleh). One solution I have considered in MinML-RPC (which generally runs in *very* memory constrained environments) is to have a fixed buffer. The result is written to the buffer. If it overflows then we continue just counting the byes and do a second pass to send the data. If it fits in the buffer then we just do one pass. This makes the small result case (which is the most likely case in an embedded system) quite quick and means the large result case works slowly as opposed to not working at all. John Wilson The Wilson Partnership http://www.wilson.co.uk
