- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Thu, 3 Jul 2003 10:41:35 -0700
- To: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>, "John J. Barton" <John_Barton@hpl.hp.com>
Another would be that it's an optimisation mechanism; i.e., it can be gracefully backed out without loss of functionality (so that you can still communicate across non-aware hops, for example). ----- Original Message ----- From: "John J. Barton" <John_Barton@hpl.hp.com> To: "Mark Nottingham" <mark.nottingham@bea.com>; "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org> Sent: Thursday, July 03, 2003 8:27 AM Subject: Re: Requirements for attachments^H^H^H transport optimisation > > A requirement related to #3, high on our list, is "early" information > on the serialization parameters. Knowing the size of objects > before they come at you on the wire allows much more efficient > response when the receiver resource are limited. Knowing that > you will not be able to handle an object allows early and more > useful user feedback. > > > > At 02:07 PM 7/2/2003 -0700, Mark Nottingham wrote: > > >I think it would be useful to spend a little time identifying the > >higher-level requirements surrounding MTOM and the like. > > > >These are the ones I'm aware of: > > > >1) Reduce "bytes on the wire", to improve bandwidth usage / transport > >latency. > >2) Reduce processing overhead during the generation and consumption of > >messages. > >3) Enable selective reordering in the serialization of message components, > >to allow flexibility in processing. > > > >The third deserves a bit more explanation; a use case might be placing a > >large binary file after the SOAP envelope in the serialized message, so > >that an intermediary (or ultimate receiver, for that matter) can act upon > >the message before reading all of the bytes off the wire. > > > >Are there any other high-level requirements associated with the abstract > >MTOM feature? I think it would be nice to call these out in the document > >at some point. > > > >It would also be good to note that these can all be seen as encoding > >issues and nothing more. > > > >Cheers, > > > >-- > >Mark Nottingham > > ______________________________________________________ > 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 Thursday, 3 July 2003 13:41:48 UTC