W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2001

Re: Proposal for resolving issue 40: Support resource constrained devices

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
Message-ID: <poa8vtk7fi3kaiukqjc510il4p4cc7781l@4ax.com>
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

Received on Thursday, 15 November 2001 15:53:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:16 UTC