- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Wed, 2 Apr 2003 13:56:00 +0100
- 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 UTC