Re: XMLP-UC-6 reformulation - simple streaming use case

As we discussed on the phone yesterday, I'm a bit nervous about the 
streaming cases, not because they are unimportant, but because I'm not 
sure I see the 80/20 point clearly.  For example, do we care about 
messages with two or more very large binary objects?  If so, is it OK to 
have to get all the way through the first before starting to buffer the 
2nd?  Certainly web browsers represent a (not necessarily SOAP) example of 
a system that prefers to make progress on multiple JPEGs, etc. in 
parallel, and one of our use cases for MTOM is go carry resource 
representation(s) in messages.  So, do we need to support interleaving? 

Maybe Mark's proposal below is indeed the simple 80/20 we seek, but I'm 
not completely convinced it goes into enough detail, or that we'll find 
consitency in users' needs if we look for such detail.  I note also that 
MTOM offers a model, a serialization trick, and an HTTP binding using the 
trick.  The requirements for the 3 need not be the same.  Consider the 
first and last, how about a requirement that says:

* The MTOM abstract inclusion feature must not preclude the creation of a 
variety of bindings, each of which might support one or more styles of 
streaming as needed in various use cases. 

* The HTTP binding provided with MTOM either (a) need not be optimized for 
streaming or ( b) SHOULD provide for accessibity to non-optimzed envelope 
information ahead of the serializations of large binary objects and SHOULD 
further  provide for streaming in the case that only one large object has 
been optimized.

I know these are requirements, not use cases, but that's how I'm thinking 
about it.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"John J. Barton" <John_Barton@hpl.hp.com>
Sent by: xml-dist-app-request@w3.org
09/17/03 09:29 PM

 
        To:     Mark Nottingham <mark.nottingham@bea.com>, Jacek Kopecky 
<jacek.kopecky@systinet.com>
        cc:     XMLP Dist App <xml-dist-app@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: XMLP-UC-6 reformulation - simple streaming use case



We also have cases where this same issue hits the entire message, 
specifically
we want to support messages that resemble xhtml-print jobs.  Here we have 
a
potentially large XML data set with potentially many interspersed binary 
objects,
some redundant (eg gif buttons, gif banner footers).  I would expect XMLP 
users
to want to deal with similar data.

At 12:55 PM 9/17/2003 -0700, Mark Nottingham wrote:


>On Wednesday, September 17, 2003, at 10:37  AM, Jacek Kopecky wrote:
>
>>Either of the parties is limited so it
>>needs to be able to produce/consume the data in a streaming fashion,
>>i.e. the SOAP Envelope must be available with only the streamed binary
>>data being in process of transmission.
>
>How about:
>
>The sender may need to produce the message without being able to buffer 
>the binary data in its entirety, and/or the receiver may need to consume 
>the message without being able to buffer the binary data in its entirety.
>
>
>
>--
>Mark Nottingham   Principal Technologist
>Office of the CTO   BEA Systems

______________________________________________________
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 Thursday, 18 September 2003 12:05:53 UTC