- From: John J. Barton <John_Barton@hpl.hp.com>
- Date: Wed, 10 Sep 2003 11:00:18 -0700
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>, Mark Nottingham <mark.nottingham@bea.com>
- Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
At 10:39 AM 9/10/2003 -0700, Anish Karmarkar wrote: >Mark, > >I mostly agree with you comments. > >XMLP-UC-6 needs to be discussed further. One of the biggest advantages of >using attachments is streaming. This can be positioned either as a usecase >or a requirement. I wonder about the use of the words "attachments" and "streaming" here. To me "attachments" means a single message with two or more parts, a major part and other stuff attached. "Streaming" means data sent continuously with out any end predicted (radio station). So the statement "advantages of using attachments is streaming" does not make sense to me. I do absolutely agree that a good mechanism for client/server interaction on buffer management is important for binary in SOAP. The simplest and a very effective way is for the protocol to allow binary object sizes to be sent in the message early. SwA can be used in this way: the entire SOAP message can appear first and a large binary can still be on the wire, allowing a client to prepare itself based on the first part of the message. >For example, consider a header containing large binary data. If this >binary data is contained in an attachment, then the sender (and receiver) >can stream the data out (and in). This allows the receiver to start >processing the SOAP message (for example looking at all the headers and >checking for MU) before the binary data has been received (or sent by the >sender). As above, I'm not sure you mean the same thing by "stream" that I commonly hear. Typically streamed data does not go over TCP/IP let alone HTTP. But otherwise I agree with the need for the requirement doc to take the case of a very large binary in to serious consideration. >Comments? > >-Anish >-- > >Mark Nottingham wrote: >> >>My .02 - >>On Wednesday, September 3, 2003, at 11:22 AM, Anish Karmarkar wrote: >> >>> >>>XMLP-UC-1: based on >>>http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/#S090 ..... >> >>Strictly speaking, this doesn't require anything beyond base64Binary. >> >>>XMLP-UC-2: an application that uses URI to deref resources, and assumes >>>the only representation travels with the message >> >>Is this still an in-scope use case? I think we need to discuss this. >> >>>XMLP-UC-3: an application that uses middleware/SOAP-stack to deref >>>resources, and assumes the only representation travels with the > message >> >>This feels more like implementation details to me, with some implied >>requirements. >> >>>XMLP-UC-4: digital camera wants to encrypt and/or sign the message >>>and/or binary data >> >>Is this a requirement (that it work with encryption/digsig)? >> >>>XMLP-UC-5: message with binary data successfully goes through SOAP 1.2 >>>intermediary >> >>Sounds like a requirement to work with intermediaries. >> >>>XMLP-UC-6: a representation is streamed upon receipt when sender and/or >>>receiver is constrained >> >>Yes; we should discuss whether this is a motivation for the work, and >>whether MTOM enables it. >> >>>XMLP-UC-7 (meta): WSDL is is applicable where appropriate >> >>Sounds like a requirement. >> >>>XMLP-UC-8: representation is a digital camera produced VLOB >> >>??? > >______________________________________________________ >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 Wednesday, 10 September 2003 14:00:52 UTC