W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2001

RE: Issue 25 Proposal

From: Jacek Kopecky <jacek@idoox.com>
Date: Wed, 20 Jun 2001 21:01:49 +0200 (CEST)
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
cc: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0106202059090.4121-100000@bimbo.in.idoox.com>
 What I meant by disallowing streaming altogether was that we
wouldn't think about any kind of streaming on the SOAP message
level and design the processing rules accordingly. Yes, anybody
could still write a streaming processor doing optimistic
optimizations and if their processing results were exactly
according to the rules, that would be OK. 8-)

                            Jacek Kopecky


On Tue, 19 Jun 2001, Henrik Frystyk Nielsen wrote:

 > Whether one writes a streaming implementation or not is not for us to
 > decide - all we have to do is to define the processing model. As of now,
 > we have a model that allows intermediaries to skip from a certain point
 > in the message and for a processor to add stuff at the end after the
 > body leaving the SOAP processing to headers referencing these trailers.
 > I am wondering what use cases we are trying to address that are not
 > covered by this?
 > It is of course always possible to use DIME or MIME multipart/related
 > for just plain old links for dealing with large chunks of data. We
 > cannot, however, in this spec set any rules for what "large" means.
 > >P.S: I'm starting to prefer the way of disallowing streaming
 > >altogether and saying "put the bloody huge data in an
 > >attachment as that's where streaming errors won't affect the
 > >validity of the whole message".
 > Henrik
Received on Wednesday, 20 June 2001 15:01:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:36 UTC