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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
