W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2003

RE: Streaming and Well-Formedness

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Wed, 2 Apr 2003 13:56:00 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A0742E@0-mail-1.hpl.hp.com>
To: "'Yves Lafon'" <ylafon@w3.org>
Cc: "'Noah Mendelsohn/Cambridge/IBM'" <noah_mendelsohn@us.ibm.com>, "'Marc Hadley'" <Marc.Hadley@Sun.COM>, "'Mark Baker'" <mbaker@idokorro.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>

[Ooops... last one escaped before I'd finished]

> On Wed, 2 Apr 2003, Williams, Stuart wrote:
> 
> > > Isn't this a perfect use case for attachements? If you know your body
will
> > > be very long compared to the envelope, then use attachements, of
course
> > > you need to have a way do do streaming of the attachements, and I'm
not
> > > sure that a MIME multipart is the best solution here, especially if
you
> > > have multiple contents to stream simultaneously.
> >
> > BEEP, BEEP :-)
> 
> Then you have multiple channels, but no way to describe a relationship
> between them, like in mime multipart, using cid:, the channels will appear
> like a request to a globally deferencable URI.
> Also there is no mechanism to wait for envelope processing (like mU check)
> before asking explicitely for the rest of the body to be sent (a bit like
> the 100 Continue of HTTP) (ie: session synchronization).

Teach me to make a cheap quip 8-)

Certainly you don't get these things straight out of the BEEP box. You'd
have to work on a BEEP binding. But I think that you could plausibly do SOAP
with streaming-attachments over something like BEEP. If each BEEP channel
within the multiplex is independently flow-controlled then you do have a
mechanism that allows you to do envelope processing first, you just don't
start reading the streams until you're ready, back pressure does the rest.
Also, envelope content could describe the structure of the multiple streams
and the intended discipline for consuming them (one after the other,
synchronously or asynchronously in parallel...). You'd probably want to
invent some scheme for naming the channels within the multiplex so that you
could make reference to them within the envelope.

Haven't done any of this... but I can't really see any show stoppers for
anyone to work through the detail in the context of *a* BEEP binding. 

> But I agree that BEEP is better at parallel streaming than other
> protocols :)
> 
> >
> > Stuart
> >

<snip/>

> -- 
> Yves Lafon - W3C
> "Baroula que barouleras, au tiéu toujou t'entourneras."
> 

Cheers,

Stuart
Received on Wednesday, 2 April 2003 07:56:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT