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

Noah,

Unfortunately I am once again confused by the use of the word "streaming".
Maybe I missed a clarification sometime back?  Mark's formulation
might be incomplete but at least I understand its terms ;-).

If I look around eg W3C almost all the uses of the term "streaming" are
for audio and video.  I did see this however:
 > SteveS: not having to download the whole package before unpacking part 
of it--streaming.
Is that the meaning of "streaming" in this context?  If so, then it is 
exactly what
we need to make some of the use cases feasible.


I also found your second paragraph confusing. Let me try to pick this apart:

 >* The HTTP binding provided with MTOM either (a) need not be optimized for
 >streaming

This reads like a non-requirement to me: why list the things the binding is not
optimized for? Well maybe the OR case is the one I want...

 >or ( b) SHOULD provide for accessibity to non-optimzed envelope
 > information ahead of the serializations of large binary objects

Well I think I understand this one: you are going to tell me the size of
stuff before you send it: I like it.

 >and SHOULD
 >further  provide for streaming in the case that only one large object has
 >been optimized

Huh? Why one?  and anyway what is streaming?  If you tell me enough
information ahead of the bits, then either I can accept your TCP/IP packets or
refuse them.  Given that we are in HTTP these are the only two things
I can do right?  I'd rather read something like:

The HTTP binding provided with MTOM SHOULD provide envelop information
ahead of optimized serializations and in a format that can be parsed before the
data for those serializations must be parsed.




At 12:01 PM 9/18/2003 -0400, noah_mendelsohn@us.ibm.com wrote:

>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

______________________________________________________
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 13:13:21 UTC