From: Mark Baker (email@example.com)
Date: Fri May 19 2000 - 03:47:42 PDT
>The big win of SOAP is that it is relatively easy to write a SOAP stack
>browser executing RPCs on remote Web servers. This then allows the browser
>to interact with interesting services.
I just finished hearing Henrik admit that SOAP was not about RPC, and that
RPC was a bad idea since the Web should be programming-model independant,
and RPC is a programming model.
I also seriously doubt it's possible to do a small implementation. There's
so much complexity in there. Perhaps you mean XML-RPC, which at least comes
clean that it *is* about RPC, and solves that problem well in a spec 1/10th
the size of SOAP.
The area that SOAP arguably has some value-add is in its encoding. But even
in that, there's some problems;
- shipping all content as */xml, thereby nullifying the value of
tried-and-true MIME in favour of namespaces-as-types (I'd prefer a
thought-out combination). Typical SOAP encodings are in fact some sort of
multipart/* type (I suggested multipart/compound+xml), yet this is not
- SOAP assumes all text/xml processors understand "href="
I'm sure there's more. I'm going to go over 1.1 with a fine tooth comb on
the plane trip back.
I must say Jim, I'm very disappointed to hear you mention RPC. As the chair
of the only working group that's done a half-decent HTTP extension (where
the methods operate on resources), I would have thought you'd be sympathetic
to those who think that RPC-over-HTTP is a mistake.
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
This archive was generated by hypermail 2b29 : Fri May 19 2000 - 03:50:53 PDT