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

[Ward Harold]

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: Last Call: Using XML-RPC in BEEP to Proposed Standard

[Ward Harold]

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: 
  C: 
  C: 
  C: 
  C: 

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: 
I:   
I: examples.getStateName
I: 
I:   
I: 41
I:   
I: 
I:   
I: END

L: RPY 1 1 . 201 100
L: Content-type: application/xml
L:
L: 
L:   
L: 
L:   
L: South Dakota
L:   
L: 
L:   
L: END

--
Best regards,
 Timurmailto:[EMAIL PROTECTED]