Re: SOAP performance data and open benchmarks

>I thought this was solved in HTTP by advertising the client's valid
>content encodings via the Accept-Encoding request header?
Yes, client may tell what it can accept, but Robin was describing the
situation when client sends compressed message, but server doesn't support
(isn't configured to support) this method. SOAP::Lite server returns 415
HTTP code, but other servers may do something else.

Best wishes, Paul.

On Wed, 16 Oct 2002 09:41:23 -0400, Jim Murphy <[email protected]>
wrote:

>I thought this was solved in HTTP by advertising the client's valid
>content encodings via the Accept-Encoding request header?
>
>If servers respected that why wouldn't it be ignored as part of the
>transport layer?  And heck, even done in hardware?
>
>Jim
>
>
>> -----Original Message-----
>> From: Discussion of implementing SOAP applications today
>> [mailto:[email protected]] On Behalf Of Robin Berjon
>> Sent: Wednesday, October 16, 2002 8:17 AM
>> To: [email protected]
>> Subject: Re: [SOAP] SOAP performance data and open benchmarks
>>
>> Neelakantan Lakshminarayan wrote:
>> > What exactly is the issue with compression and interoperability? If
>the
>> > compression algorithms are well known - gzip for example - is there
>> still an
>> > issue? I'm trying to understand what it is that we lose if chose to
>> compress
>> > SOAP messages.
>>
>> If the other end doesn't support the compression your are using --
>well
>> known or not -- then you lose interoperability. That's a problem I am
>> currently facing as I am working on a prototype to provide binary XML
>> serialisation (with much smaller messages and much faster parsing) for
>> SOAP.
>>
>> Issues of making it available to all implementations are solvable with
>> pluggable components such as JAX-RPC's XMLWriter and XMLReader (I wish
>> all Java implementations supported that, and better that
>implementations
>> in other languages had similar common interfaces -- it makes a lot of
>> sense wrt the SOAP spec).
>>
>> However issues of "how to know that you can use that with the other
>end"
>> are much harder. Restricting yourself to the HTTP binding, you can
>rely
>> on the same approach that SOAP::Lite does which is to test for a 415
>> error, but that's not very pleasant. I guess that might be a candidate
>> for something that is to be specified at a higher level.
>>
>> --
>> Robin Berjon <[email protected]>
>> Research Engineer, Expway
>> 7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488
>>
>> You can read messages from the SOAP archive, unsubscribe from SOAP, or
>> subscribe to other
>> DevelopMentor lists at http://discuss.develop.com.
>
>You can read messages from the SOAP archive, unsubscribe from SOAP, or
subscribe to other
>DevelopMentor lists at http://discuss.develop.com.

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