Subject: Re: Re[2]: Last Call: Using XML-RPC in BEEP to Proposed Standard

From: Ward Harold <[email-masked]>
Date: Fri, 11 Oct 2002 09:45:39 -0500

As John says XML-RPC actually predates SOAP. It's also simpler and thus
easier to implement but SOAP has better support for handling complex types.
Ultimately you have to choose the one that best meets your application
requirements. I do feel strongly that HTTP is the wrong transport protocol
for an RPC mechanism; BEEP is a much better choice.

... WkH

p.s. RFC 3288 describes how to use SOAP over BEEP

                      Timur Shemsedinov
                      <[email-masked]        To:       Ward Harold/Austin/IBM@IBMUS
                      pi.kiev.ua>               cc:       [email-masked], [email-masked]
                                                Subject:  Re[2]: Last Call: Using XML-RPC in BEEP to Proposed Standard
                      10/11/2002 03:38
                      AM
                      Please respond to
                      Timur Shemsedinov

Ward,
thanks for explanations and references. I have one more question.
XMLRPC is similar to SOAP in abilities and applications,
as I understand. But on my personal opinion, if to compare,
XMLRPC has much more winning data representation. "Envelope" is
terrible itself. Here question, whether is necessary to have two
realizations of the RPC using XML? I think that it is not profits
integration and compatibility. It seems to me that it is necessary
to seek cooperation between developers for establishing of the
trade-off decision.

--
Best regards,
 Timur                            mailto:[email-masked]

---

From: [email-masked]
Date: Fri, 11 Oct 2002 15:07:44 -0400

> for an RPC mechanism; BEEP is a much better choice.

HTTP has the advantage of usually being passed by firewalls.

Now take a deep breath and ask yourself "What's wrong with this picture?" :)

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 12 Oct 2002 00:24:43 +0100 (BST)

> for an RPC mechanism; BEEP is a much better choice.

HTTP and BEEP aren't transport protocols.

session and transfer protocols, perhaps.

Since they both run over TCP, they're both completely wrong for RPC.

L.

XMLRPC - it's not XML, and it's not RPC.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 11 Oct 2002 18:50:29 -0500

On 10/11/02, Ward Harold wrote:

>
>As John says XML-RPC actually predates SOAP. It's also
>simpler and thus easier to implement but SOAP has better
>support for handling complex types. Ultimately you have to
>choose the one that best meets your application
>requirements.
>

> p.s. RFC 3288 describes how to use SOAP over BEEP

For systems that have to support SOAP *anyway*, XML-RPC
would be an additional feature to implement. If a
developer already has a SOAP implementation available,
are there any justifications for using XML-RPC?

- Reduced code space?
- Shorter messages to accomplish the same calls?
- More robust handling of any conditions?

I'm not throwing these out as rhetorical questions.
These are just the types of justifications I would want
for maintaining two options, rather than settling on one.

A quick google scan for justifications mostly came up
with arguments on why XML-RPC would be better *instead
of* SOAP. Are there valid arguments on why it is a
valuable tool *in addition to* SOAP?

Caitlin Bestler
http://asomi.com/CaitlinBestler/

---

From: Timur Shemsedinov <[email-masked]>
Date: Mon, 14 Oct 2002 12:17:37 +0300

Hello Lloyd,

LW> HTTP and BEEP aren't transport protocols.
LW> session and transfer protocols, perhaps.
LW> Since they both run over TCP, they're both completely wrong for RPC.
LW> XMLRPC - it's not XML, and it's not RPC.
You are absolutely right concerning HTTP and BEEP, but I suppose
that choice of mentioned protocols as a "transport" layer for SOAP
and XMLRPC can be explained by the fact that it simplifies PROXY
access. It is very important, but it should not break networking
principles. Thus BEEP reintroduces such TCP features as port
multiplexing and sliding window flow control. Besides the modern
applications require high level RPC mechanisms giving facilities
for complex structured data transmission (documents, objects, etc.).

Best regards,
Timur
mailto:[email-masked]