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:43:44 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A0742D@0-mail-1.hpl.hp.com>
To: "'Yves Lafon'" <ylafon@w3.org>, "Williams, Stuart" <skw@hplb.hpl.hp.com>
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

> 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-)

C

> But I agree that BEEP is better at parallel streaming than other
> protocols :)
> 
> >
> > Stuart
> >
> > > -----Original Message-----
> > > From: Yves Lafon [mailto:ylafon@w3.org]
> > > Sent: 02 April 2003 12:12
> > > To: Noah Mendelsohn/Cambridge/IBM
> > > Cc: Marc Hadley; Mark Baker; xml-dist-app@w3.org
> > > Subject: Re: Streaming and Well-Formedness
> > >
> > >
> > >
> > > On Tue, 1 Apr 2003, Noah Mendelsohn/Cambridge/IBM wrote:
> > >
> > > > What worries me more is streaming request/response, which
> > > may be a use
> > > > case that doesn't make the 80/20 cut.  Let's say I want 
> to define an
> > > > "uppercase this string" service, which returns some 
> body string in
> > > > uppercase.  If the string is 1GByte long, it would be nice
> > > to stream the
> > > > response while the request is coming in, and indeed
> > > deadlock avoidance may
> > > > require it.  If the input later proves to be
> > > not-well-formed, how do you
> > > > reflect the fault?  That's the case that worry's me 
> more, at least
> > > > architecturally.  It's probably less common in practice.
> > >
> > > 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.
> > >
> > > --
> > > Yves Lafon - W3C
> > > "Baroula que barouleras, au tiéu toujou t'entourneras."
> > >
> >
> 
> -- 
> Yves Lafon - W3C
> "Baroula que barouleras, au tiéu toujou t'entourneras."
> 
Received on Wednesday, 2 April 2003 07:44:20 GMT

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