RE: AFTF requirements, pre-2003/01/31 telcon

The primary design point for SOAP is a single data entity roughly like
a document. To bundle a stream with the SOAP model you must place
the stream after the SOAP and any attachments, you must have a single
stream, and you must send the stream over the same packet protocol
as the SOAP message.  All of this is possible, but none is desirable.
Dictating the order of attachments in the spec adds complication.
Limiting applications to a single stream is restrictive.  Using TCP/IP
for streams may not be good engineering in many cases.  Rather than
designing for this narrow special case I urge you to consider a model in
which the  SOAP message preps the receiver for the stream which is then
sent on another socket or at least logically out of the SOAP channel.
Packing a URI for a streaming protocol in a SOAP message would
enable all of the powerful SOAP technology to work with out mucking up
the packaging with issue its not too good at resolving.

At 09:52 PM 2/3/2003 -0500, Rich Salz wrote:

> > Ok, so now I am complete confused.  The likely outcome from the AFTF
> > effort would be a specification that would lead to a software component
> > in a SOAP engine preceding XML parsing.  The component would pull
> > bits off the wire and prepare them for application level processing.
>
>I hope it's not going to be required that ALL bits be pulled off the wire
>before being processed. I'd like to use SOAP with streaming media.
>(I think that also argues against the Infoset proposal.)
>         /r$

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Monday, 3 February 2003 23:39:11 UTC