Re: ordering [was: regarding the resolution of issue 431]

Mark, 

as the abstract optimization feature doesn't speak about what the
optimization is going to be, and specifically it doesn't speak about any
kind of splitting of the Envelope into different parts, it should not
try and provide for ordering of those.

The concrete implementation can have properties like ordering if we find
it useful. But the abstract feature and its processing described in
section 2 should not be affected.

To illustrate an implementation that does not introduce ordering, let me
mention again a possible optimization of the transmission of blocks of
the SOAP messages by compressing them (likely very effective on XML, say
70% decrease in size) and putting the result as base64 (33% increase in
size) back in the message, which would mean 60% decrease in size of
transferred XML data. As all stays in the envelope and in the same
order, there are no parts that could be reordered.

Best regards,

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/






On Wed, 2003-07-16 at 20:11, Mark Nottingham wrote:
> I certainly agree that preserving order shouldn't be required, but it 
> may be that ordering profoundly affects the nature of the optimisation, 
> and therefore may be interesting to model (probably as a property).
> 
> I.e., because we're doing optimisation, the message will always be 
> isomorphic to XML, so the ordering of MIME parts in the serialization 
> doesn't matter. There may be cases, however, where the ordering does 
> affect the message's performance characteristics.
> 
> For example, SOAP with Attachments allows for the SOAP envelope to 
> appear anywhere in the MIME package, as long as it's referenced 
> properly with the start parameter; this is derived from MIME multipart 
> packaging. If one were to place the SOAP envelope after all of the 
> attachments, however, intermediaries would be forced to buffer 
> everything before it (potentially many megabytes) before making a 
> decision about the message.
> 
> This is an extreme example, but I believe there may be use cases for 
> ordered optimisation that are more subtle (including some where the 
> SOAP envelope is still packaged up-front).
> 
> The alternative is to not talk about ordering at all. The status quo is 
> that the sending implementation determines the optimal ordering, which 
> may or may not be correct.
> 
> Without the ability to direct the ordering of MIME parts, MTOM only 
> allows optimisation by reduced size on the wire and reduced processing 
> overhead. If those are our only goals, it seems to me that we can 
> easily adopt a much less convoluted representation than SOAP over MIME 
> multipart.
> 
> Cheers,
> 
> 
> On Tuesday, July 15, 2003, at 06:23 AM, Christopher B Ferris wrote:
> 
> > Hmmm...
> >
> > It isn't clear to me that preserving order is a necessarily good idea. 
> > In
> > fact, I think
> > that no significance should be accorded the order of parts carried as
> > attachments.
> >
> > Cheers,
> >
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > phone: +1 508 234 3624
> >
> > xml-dist-app-request@w3.org wrote on 07/14/2003 01:50:30 PM:
> >
> >>
> >> On Friday, Jul 11, 2003, at 07:41 US/Eastern, Jacek Kopecky wrote:
> >>>
> >>> I also motion to close the (narrower) issue 431 because there seems 
> >>> to
> >>> be consensus in the WG that intermediaries can, in general, change
> > what
> >>> is optimized. If we come up with a requirement that is contrary to
> > this
> >>> (which seems extremely unlikely, considering the voices in the group)
> >>> the requirement will be a new information and we'll happily reopen 
> >>> the
> >>> issue.
> >>>
> >> As an example, somebody (I don't remember who) mentioned, during the
> >> last telcon, a requirement that attachment order be preserved. I think
> >> its premature to start closing potentially related issues until such
> >> requirements are clear. Of course we can always close then re-open
> >> issues, but what's the point in doing that ?
> >>
> >> Marc.
> >>
> >> --
> >> Marc Hadley <marc.hadley@sun.com>
> >> Web Technologies and Standards, Sun Microsystems.
> >>

Received on Thursday, 17 July 2003 04:18:40 UTC