Re[4]: Last Call: Using XML-RPC in BEEP to Proposed Standard
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 PROTECTED]
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: Last Call: Using XML-RPC in BEEP to Proposed Standard
Timur Shemsedinov wrote: Here question, whether is necessary to have two realizations of the RPC using XML? Again, it's not up to the IETF; XML-RPC already exists. And, in fact, it predates SOAP. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
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/
Re: Last Call: Using XML-RPC in BEEP to Proposed Standard
http://www.ietf.org/internet-drafts/draft-harold-beep-xmlrpc-00.txt There are some questions concerning xmlrpc and some, most probably, even beep. 1. How it can work in local networks if IANA is not accessible and profiles can be received neither from the client nor from the server of such network? Or they are placed locally, if so why URL refers to iana.org ? I believe that it works, but how? It is not clearly documented by BEEP specification and is not considered in mentioned draft. C: start number='1' serverName='stateserver.example.com' C: profile uri='http://iana.org/beep/transient/xmlrpc' C: ![CDATA[bootmsg resource='/NumberToName' /]] C: /profile C: /start 2. Few examples are given in the document, it is difficult to get complete understanding of the complex structured parameters representation. 3. Looking on the following example, any person can have idea, whether it is impossible to represent a call briefly and gracefully even using XML? I: MSG 1 1 . 0 364 I: Content-Type: application/xml I: I: ?xml version=1.0? I: methodCall I: methodNameexamples.getStateName/methodName I: params I: param I: valuei441/i4/value I: /param I: /params I: /methodCall I: END L: RPY 1 1 . 201 100 L: Content-type: application/xml L: L: ?xml version=1.0? L: methodResponse L: params L: param L: valuestringSouth Dakota/string/value L: /param L: /params L: /methodRespose L: END -- Best regards, Timurmailto:[EMAIL PROTECTED]
Re: Last Call: Using XML-RPC in BEEP to Proposed Standard
Timur Shemsedinov wrote: 1. How it can work in local networks if IANA is not accessible and profiles can be received neither from the client nor from the server of such network? Or they are placed locally, if so why URL refers to iana.org ? It's not used as a URL; it's used as a URI. You don't resolve it; you just use it as an identifier. This is a common tactic in XML. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: Last Call: Using XML-RPC in BEEP to Proposed Standard
Timur, my responses to your questions follow: 1. The uri attribute associated with a start message's profile element is equivalent to an XML namespace name. It is a URI that uniquely identifies a BEEP profile; it is just an identifier and does not necessarily point to anything on the Web. 2. The methodCall, methodResponse, and associated parameter encodings are all defined by the XML-RPC specification: http://www.xmlrpc.com/spec. The draft explains how to use BEEP to transfer XML-RPC encoded messages between peers not how to actually do the encoding. 3. Grace and beauty are in the eye of the beholder; regarding brevity it is no doubt possible to define a more compact encoding, even using XML, but in this case the XML-RPC authors defined what they defined. ... WkH Timur Shemsedinov [EMAIL PROTECTED]To: Ward Harold/Austin/IBM@IBMUS pi.kiev.ua cc: [EMAIL PROTECTED] Subject: Re: Last Call: Using XML-RPC in BEEP to Proposed Standard 10/10/2002 12:08 PM Please respond to Timur Shemsedinov http://www.ietf.org/internet-drafts/draft-harold-beep-xmlrpc-00.txt There are some questions concerning xmlrpc and some, most probably, even beep. 1. How it can work in local networks if IANA is not accessible and profiles can be received neither from the client nor from the server of such network? Or they are placed locally, if so why URL refers to iana.org ? I believe that it works, but how? It is not clearly documented by BEEP specification and is not considered in mentioned draft. C: start number='1' serverName='stateserver.example.com' C: profile uri='http://iana.org/beep/transient/xmlrpc' C: ![CDATA[bootmsg resource='/NumberToName' /]] C: /profile C: /start 2. Few examples are given in the document, it is difficult to get complete understanding of the complex structured parameters representation. 3. Looking on the following example, any person can have idea, whether it is impossible to represent a call briefly and gracefully even using XML? I: MSG 1 1 . 0 364 I: Content-Type: application/xml I: I: ?xml version=1.0? I: methodCall I: methodNameexamples.getStateName/methodName I: params I: param I: valuei441/i4/value I: /param I: /params I: /methodCall I: END L: RPY 1 1 . 201 100 L: Content-type: application/xml L: L: ?xml version=1.0? L: methodResponse L: params L: param L: valuestringSouth Dakota/string/value L: /param L: /params L: /methodRespose L: END -- Best regards, Timurmailto:[EMAIL PROTECTED]
