I think the documentation is so good I'll actually be able to understand this here XML-RPC, and use it.

This is a great addition to 5.0 (or 5.1), thank you Vinod!

Do you know if it will work to serve requests from Jerry's nsvhr/nsunix virtual hosting?

Vinod, that sounds excellent! It should be very useful to have xmlrpc supported in OpenACS.

However, are you sure that ns_xmlrpc was is best foundation to build on? I had lots of problems and failures during some initial experimenation and testing with it back in July 2002. Besides just plain nasty bugs, I remember ns_xmlrpc didn't do any automatic converson between XML-RPC and Tcl data structures at all, even though that's obviously one of the most useful things and Tcl xmlrpc package like that could do. Pretty kludgy.

At the time, people said that TclSOAP was definitely the better (best) tool to use for XML-RPC from Tcl or AOLserver, which I think has used tDOM all alongfor its's XML stuff. I never tried it however, nor do I know which of ns_xmlrpc's old failings (besides the bugs, presumaby) it improves upon.

Maybe ns_xmlrpc was improved since then though? Is it all working to your satisfaction, or should we be encouraging somebody to still look into using TclSOAP instead?

Hm, is William Byrne's SOAP Gateway package from January 2003 relevant in any way?

Hey Andrew,

I did look at the SOAP-Gateway package which seems real nice and should be useful for SOAP. I couldn't, in my brief inspection, figure out how to have it do plain XML-RPC, it only took care of SOAP requests.

I'm not sure if ns_xmlrpc was the best foundation to start with, but it was the quickest. I wanted to use tDOM since we were already using tDOM in OpenACS 5, therefore I didn't look at TclSOAP. I fixed a few bugs here and there and it seems to work well.

But, I didn't do the automatic conversion between Tcl and XML-RPC that you mention. I thought about doing it, but I couldn't figure out a clean way to do it. XML-RPC to Tcl conversion is automatic (which is easy since Tcl doesn't care about datatypes). But Tcl to XML-RPC conversion requires the programmer to specify the datatype that he's returning. i.e. return [list -int 23]. Now in some cases, it would be very easy to figure out the datatype from the value and take care of that little detail ourselves. For example, 23 is an int. But what if you're implementing a method that's supposed to return a string, whose value happens to be 23. Our XML-RPC would look at 23, call it an int and return an int. If the XML-RPC client on the other side is using a strongly-typed language, it would be expecting a string and might fail. A similar problem would be trying to differentiate between XML-RPC arrays and structs. In TCL, these are arrays and lists, respectively. But if your proc returns a list with 4 items, there's no way to tell if I should code that as an XML-RPC array of 4 items or an XML-RPC struct with 2 name-value pairs (or even as an XML-RPC string with four words). We'd have to have a way of procs specifying their signature (with datatypes) somewhere and that seemed harder to implement than having the programmer specify the datatype.

Thanks for the reminder Til - I haven't looked at this stuff since my last post. I'll plan on committing it to HEAD this weekend unless I hear differently.

I'm having a problem with the xmlrpc package - for any xmlrpc request it hangs for appx. 30 seconds and then errors out, with this in the error log:

Error writing content: resource temporarily unavailable
    while executing
"ns_conncptofp $fp"
    (procedure "xmlrpc::get_content" line 13)
    invoked from within
"xmlrpc::get_content"
    invoked from within
"if {[string equal [ns_conn method] POST]} {
...

It is mounted on /RPC2 as per the default. Which gets redirected to /RPC2/ by the way, didn't you want to make it a registered proc once to avoid that? But that is not the problem I think - the client seems to follow the redirect correctly. I tried both xmlrpc::remote_cal from another openacs installation and the python client api.

This is happening on AOLserver 3.3.1+ad13 which is running on a non-standard port number, without any proxies involved. One empty temporary file like /tmp/fileddoVAw-562318384.xmlrpc2 is left after each attempt.

Any ideas?

Hey Talli, did the AOL folks ever release that tdom-based xml-rpc code you were talking about above, back in Oct. 2003?

excellent!
Bart, are going to put this into oacs cvs rep?

Versions 1.2 of the new XML-RPC client/server have been released. Version 1.2 simplifies the creation of XML-RPC messages. Upgrading is recommended but not required.

Messages created by a client of version 1.2 are compatible with all XML-RPC servers. Client and server don't have to be of the same version number.

See http://www.thecodemill.biz/services/xml-rpc/ for more details.

An reference implementation of the XML-RPC test suite is available at http://www.thecodemill.biz/RPC2. Point you XML-RPC client to this URL to test your client installation.

/Bart

Thanks, Andrew. The server half is /almost/ done. Just trying to decide if it should use NSV's to store the method-to-proc mapping or not. It probably should ...

Keep in mind that Dossy's "ns_xmlrpc" module mentioned above is entirely different from the "ns_xmlrpc" code in OpenACS CVS which I tried using a bit back in 2002, and is also distinct from the xmlrpc in AOLserver SourceForge CVS.

There is also now Malte and Timo's tsoap package, in the OpenACS CVS.