In this case I feel MTOM is oversold as it stands. Where is the optimization making things smaller not larger? Given we can compress a content and make it an attachment it might be worth to look for SwA (SOAP with Attachments). Or does somebody more knowledge to the basic subject have a better idea? I like to learn as well. Josef
-----Ursprüngliche Nachricht----- Von: Andreas Veithen [mailto:[email protected]] Gesendet: Donnerstag, 10. November 2011 19:35 An: Apache AXIS C User List Betreff: Re: Axis2c and deflate_module On Thu, Nov 10, 2011 at 15:07, Stadelmann Josef <[email protected]> wrote: > Doing zip and unzip in the proper order is definitely a job for MTOM. > > How shall axis2 or one of its message receiver know where the zipped section > in a stream of bytes starts/ends? Axis for sure has no clue about that. But > MTOM has. That is not correct. MTOM is based on MIME, more precisely on the part that describes MIME multipart messages. MIME only supports Content-Transfer-Encoding (base64, binary, quoted-printable, etc.), but not Content-Encoding. HTTP on the other hand supports Content-Encoding (e.g. gzip) and Transfer-Encoding (e.g. chunked). That means that MTOM doesn't handle compression. Compression can only be handled in two places in the stack: at the transport level (HTTP) or in the application (service implementation). It is not MTOM's business. Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
