Re: customized encoding and SOAP interoperability

-----Original Message-----
From: Neela Lakshminarayan [mailto:[email protected]]
> Your suggestion sounds good...and it could co-exist with my "hideous
hack".
> Thanks!

Just to be clear, the "hideous hack" is the compression of the entire
SOAP message, instead of using the mechanisms SOAP provides for adding
special handling of message parts, with reliance on some error-handling
behavior at the transport level to enable interoperable SOAP messaging.
That comes close to criminal behavior! The compression itself isn't
hideous, but likely to be ineffective, as another poster also argued.

> From the preliminary studies we've done, it seems that in some situations
> (typical to us) compression does pay off.

It may always be true for very special circumstances, but needs to be
examined very carefully in light of many years of collective experience with
XML which has not yet yielded any compelling use cases for it.

> We would need to change a lot of processes to ignore compression and get
the
> same benefit.

This argument seems to me not so good. If you did happen to go down the
wrong
path going further down that path, if it is known that it does not go where
you want, is eventually going to just cost your project more pain.

> In the long term - I agree that streamlining the processes will yield
larger
> returns. But even so, compression and streamlined processes could
co-exist,
> couldn't they?

Certainly.

Michael

You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other
DevelopMentor lists at http://discuss.develop.com.