Re: Re[2]: Last Call: Using XML-RPC in BEEP to Proposed Standard
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 PROTECTED]To: Ward Harold/Austin/IBM@IBMUS pi.kiev.ua cc: [EMAIL PROTECTED], [EMAIL PROTECTED] 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, Timurmailto:[EMAIL PROTECTED]
Re: Re[2]: Last Call: Using XML-RPC in BEEP to Proposed Standard
On Fri, 11 Oct 2002 09:45:39 CDT, Ward Harold said: requirements. I do feel strongly that HTTP is the wrong transport protocol 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? :) msg09126/pgp0.pgp Description: PGP signature
Re: Re[2]: Last Call: Using XML-RPC in BEEP to Proposed Standard
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/
