- From: Simon Fell <soap@zaks.demon.co.uk>
- Date: Thu, 15 Nov 2001 12:57:16 -0800
- To: Noah_Mendelsohn@lotus.com, xml-dist-app@w3.org
On Thu, 15 Nov 2001 14:15:27 -0500, in soap you wrote: >Jacek Kopecky writes: > >>> IMO the scenario S21 is perfectly doable once >>> we assert (as IIRC we have decided to do) >>> that the headers are relatively small and >>> that the body is the biggie. > >+1 insofar as streaming is known to more important for bodies in general. > >That said, I'm not sure we've done a particularly good job characterizing >the requirements for resource constrained devices. Many such devices will >either (a) receive small messages (b) have the horsepower to quickly >receive and do random access to moderately larger messages. One can >certainly imagine scenarios (incremental rendering of JPEGs, playing >music) where it's important to do streaming, though for many of these >streaming of the body indeed seems to be what you need. Bottom line: I >think we need to do a better job of identifying the real requirements of >various small device usage scenarios before we go too far out of our way >on design issues. One problem I've seen raised with xml-rpc and soap 1.1 for streaming is the inability to abort streaming a message, and switch to streaming a fault, requiring the code to buffer as much of the body as it takes to work out there'll be no faults later. I would imagine that high performance intermediaries may have similar issues with not wanting to read and buffer the whole request before starting sending the next hop. Cheers Simon
Received on Thursday, 15 November 2001 15:53:26 UTC