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

RE: Streaming and Well-Formedness

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 2 Apr 2003 14:07:40 +0200 (MEST)
To: "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
Message-ID: <Pine.GSO.4.53.0304021352080.958@tarantula.inria.fr>

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).
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:11:40 GMT

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