Forum OpenACS Development: XML-RPC module

Collapse
Posted by carl garland on
I have been looking at extending the current xml-rpc module/work that I found over at www.thedesignexperience.org (Can't remember link) For those who want some background on xml-rpc go to www.xmlrpc.com and you should get up to speed within a couple of hours unlike SOAP which has a much steeper learning curve.

What I have been thinking about doesn't really abstract out the (problem/solution) of general web services(WDSL/UDDI/SOAP/XMLRPC) but just deals with extending the xmlrpc AOLserver module. Also much thanks to those who have gotten the code this far (Steve Ball, Hafeez Bana, Dave Bauer, Jerry Asher, and anyone else I've overlooked)

Sorry I don't have time for a full design document but here are my thoughts/plans for the module.
Adding system calls extension to the module
For background go here Basically it adds 3 methods
  • system.listMethods Returns all methods that are registered on the individual instance xmlrpc server
  • system.methodSignature Returns an array of all possible signatures for a single method (xmlrpc allows overloading)
  • system.methodHelp Return a documentation string for an individual function.
Currently our xmlrpc module basically registers all rpc procs by adding a variable equal to the procedure to call to an nsv array named xmlrpc_procs.

So to add new xmlrpc call you would define your procedure and then call [xmlrpc_register_proc proc_name] which simply currently does nsv_set xmlrpc_procs $proc_name $proc_name

I suggest modifying the proc to accept a documentation string and a list of signatures/procedure names to allow for overloading. These values would be saved in the nsv array and allow for easy implementation of all the system. extensions.


Adding parameter checking upon invocation
The xmlrpc spec allows for returning faultcodes/errors but our xmlrpc module only returns them for malformed xml requests. I suggest reworking the code that currently invokes whatever method we are calling to first check to make sure that it is being called with an allowed parameter list. Most xmlrpc implementations already do this and ours is lagging behind. I having been debating whether to do this in each registered proc but I think it could be abstracted out by using our information that we have saved in our nsv array and allows us to have a one to many mapping corresponding to the function overloading.

Adding the system.multicall function
For background go here basically this adds the functionality of packing multiple asyncronous calls to the server in one request and returning all the result sets saving bandwidth and latency. While I see this as being very useful it is last on my current priorities here and shouldn't be too difficult once the other items have been implemented.

Creating a tcl/adp page to mimic the debugging/testing functionality found here
This page is very useful but I would like a local version for non-net and think it would come in handy.

All of the above items are pretty much AOLserver module items and not dependent on any OpenACS features but there may be things that should be considered that I am overlooking. Down the line there probably should be some abstract wrapper for general web services implementation but the above items shouldn't be too difficult to implement and hopefully useful to community. Questions/comments?
Collapse
2: Response to XML-RPC module (response to 1)
Posted by Dave Bauer on
Carl,

This sounds great. I am also looking into getting tclSOAP [1] working in AOLserver. It will provide for access to SOAP and XMLRPC.
I am not sure how much of your ideas it addresses for XMLRPC.

[1] http://tclsoap.sourceforge.net

Collapse
3: Response to XML-RPC module (response to 1)
Posted by Dave Bauer on
Carl, any updates on XMLRPC in OpenACS/AOLserver?