On the topic of XML-RPC, input needed... (Long and Related to: XML-RPC Stack almost there)

[Andre Garzia]

Hi Folks,

I want to spawn in this list a discussion on what sould the best way to 
create the server part of a xml-rpc implementation. The client part is 
easy and straight forward, it's almost done, in one week or two i'll 
release it to the community. The server part is the tricky one. I never 
implemented the server part before (i did implement the client on a 
couple plataforms, thats why i choose to do it first). The client part 
will enable us to call lot's of cool public avaiable methods on the net 
(like spell checkers, blog apis, storage systems) and talk to 
proprietary apps that export this kind of stuff (MyST for example).

But, if we want to serve methods, how should us procced? For thoose 
unfamiliar with the xml-rpc spec the url is: http://www.xmlrpc.com The 
specs are pretty easy, and there's a document called "Xml-Rpc for 
newbies" which will cover any info you might need. Now let's get back 
to our topic. What we will receive from a client is an HTTP POST 
Request with XML content detailing what he wants to do (It's a method 
call and it's parameters inside the xml). What xml-rpc call methods is 
similiar to what revolution call function, so what the client is trying 
to do is make a remote call to a function and retrieve it's results. To 
implement this behaviour we can decide to follow two very different 
aproaches:

Aproach #1: The Hard Way.
Implement a custom HTTP Server that will listen to xml-rpc requests. 
Implement the xml-rpc server layer on top of it. There's a MetaCard 
HTTPd stack that fills the HTTP server part, just need to plug the 
xml-rpc part in it. Advantages of this aproach are: Make an app 
self-contained and not depend of any other thing to serve xml-rpc 
methods (thats a huge advantage). Disadvantages: More work to do, must 
fiddle with raw sockets and stuff to implement a HTTP Server thats 
fail-proof.

Aproach #2: The Easy Way.
Set up a middleware, a simple CGI Stack in revolution that would gather 
the call, and deliver it to the correct stack. This middleware is easy 
to do for it must not know about HTTP or raw sockets, it must know only 
how to gather post data from it's CGI Enviroment, parse it, make the 
call, present the results. Since everything after the CGI Enviroment 
data parsing must be implmented by both solutions, This aproach is a 
quick, very quick solution and it's code could be reused in aproach #1. 
Advantages: Very quick to implement. Disadvantages: Our apps would need 
an external webserver (Apache, IIS, Xitami...).

I am thinking of making aproach two, and then, maybe trying aproach one 
altought I do think I am not good enought to create my own HTTP Server 
stack. But let's talk about what is common to both aproaches, the 
XML-RPC Layer. As told before, what we will receive is a simple XML 
with a function and it's parameters. Let me quote an example in here:

<?xml version="1.0"?>
<methodCall>
  <methodName>examples.getStateName</methodName>
    <params>
       <param>
          <value><i4>23</i4></value>
          </param>
       </params>
    </methodCall>


See, what is the method: "example.getStateName", what is the 
paramenter: the number 23. This call on http://betty.userland.com would 
return the state name of the 23 state of the united states of america. 
The params part can hold an array (or struct) of parameters, each 
parameter receive it's own node with name and value. The types allowed 
are the commons ones (string, boolean, date, integer...). A sample 
answer would be:

<?xml version="1.0"?>
<methodResponse>
	<params>
		<param>
			<value>Minnesota</value>
			</param>
		</params>
</methodResponse>


See, the 23th state is called Minnesota. This xml were extracted from 
my xml-rpc stack, they are real. It's easier than SOAP, it's straight 
and simple. But again, let's get back to the topic. What I am thinking 
about? I am thinking of how to relay the xml call to the correct 
function on a stack, it's more theory than practice now. I am thinking 
of this:

<?xml version="1.0"?>
<methodCall>
  <methodName>MainStack.addToField</methodName>
    <params>
       <param>
          <value><string>All your remote methods are belong to 
us</string></value>
          </param>
       </params>
    </methodCall>

This call would be sent to function call "addToField" of your 
mainstack. The first part before the dot could be the stack, the second 
part the method. we could go further to use even <name of the 
stack>.<name of the card>.<function to call> structure (Ex: 
MainStack.report.addToReport), if the stack is not present in memory, 
it would search for a file with the same name, load it and send the 
function call to it... the return would be echoed to remote client. 
Since rev function can return only one parameter, we could create help 
functions to assemble everything we want to return in one huge string 
(Thats what base64 is for) and decode it on client.

That would make possible to rev stacks running in different computers 
to share data across the internet and bypass all firewall for no one 
sane blocks port 80. For thoose that read this far and are yet to see 
the benefits of XML-RPC in their app let me try to clarify the 
advantages:

* our only viable alternative is SOAP and SOAP is simple an annoying, 
strange, complex piece of burocracy. But it's already implemented in 
Rev.

* With XML-RPC and it's simplicity, you can make your cross plataform 
data sharing a dream. You'll be able to make a Mac app for your design 
department that actually will talk to the Linux app in your network 
administration department and both will talk to your account management 
department using windows, all this with no harm to your firewalls 
policies.

* Please read "Beyond the Browser" Article in Fourth World Embassy 
(http://www.fourthworld.com/embassy/articles/netapps.html), it's about 
rediscovering the desktop after the web boom. It's a very good reading, 
and will make you think about how your apps can make this networking 
dream come true.

I dream some day to be able to write:

send "Example.GetStateName 41" to URL http://betty.userland.com/RPC2

and it would travel the network just as easy as it travels my stacks, 
but until that day come, we must settle good founding stones. I am just 
a Revolution Newbie, my Studio License arrived only couple weeks ago... 
There are lots of RevGurus (and RevGuruess if this word exists) that 
could offer their two cents of code in making this protocol 
implementation come true. I want to know from users out there how they 
want it done so that we can make a success from the start and not 
keeping reinventing the wheel evey time we need some feature added.

Cheers

Andre Alves Garzia  2003  BRAZIL
http://www.soapdog.org