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

If an intermediary can repackage, then we'll want to re-order.  For example,
consider a stream of mixed binaries with repeats.  Some clients will be
best served with single copies of each binary (minimal bandwidth); others
with duplicate copies in the order they need to be processes.  Someday
we may have intermediaries to help service each equally well.

At 11:11 AM 7/16/2003 -0700, 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.
>>
>>______________________________________________________
>>John J. Barton          email:  John_Barton@hpl.hp.com
>>http://www.hpl.hp.com/personal/John_Barton/index.htm
>>MS 1U-17  Hewlett-Packard Labs
>>1501 Page Mill Road              phone: (650)-236-2888
>>Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Wednesday, 16 July 2003 15:12:45 UTC