No, no, no and no ! (I should be make some nuances though) The XML-RPC specification experessedly specify that the Content-Length of the XML-RPC message is part of the header so, unless you are doing it in special cases where you would know the size in advance (and would then need to modify the current library), it is not possible.
Stop, don't be scandalized like I was the first time I read this. There's half a ton of good reasons you do want to know this size in advance. For example, to allocate buffers for easier parsing. But also to master resources in general. Still looks like a pity ?? Second you would need the complete API to be changed to support streaming progress monitoring, so the great simple execute(String methodName, Vector params) would no more be true (and the even easier direct calls to an object would also be impossible). You would need some delicate objects instead. XML-RPC is simple and that makes its strength !! (simply compare the number of implementations for XML-RPC to the ones for SOAP) Well... why not, simply build streaming ON TOP of XML-RPC ?? That is the way to go, believe me. You request a URL to start sending your chunks. You then send each of your chunks to this URL (which presumably calls another method that makes the storage, processing and monitoring of the calls) and call the close method. Advantages ? If only half of the data is through, it may be usable. Better resource control and... This should definitely be in some FAQ. This together with an answer to the question "Why can't I put some XML in the middle of an XML-RPC call if not as a string ?". Paul On Mercredi, mars 6, 2002, at 05:44 , Alain K wrote: > Hello, > > Is it possible to send large data via xmlrpc without > loading everything into memory first using some kind > of streaming mecanism. > > Thanks for your help. > > Alain. > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com >
