Forum OpenACS Development: Re: XML-RPC package ready

Collapse
4: Re: XML-RPC package ready (response to 1)
Posted by Andrew Piskorski on
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?

Collapse
5: Re: XML-RPC package ready (response to 4)
Posted by Andrew Piskorski on
Oh, oops, TclSOAP appears to use TclDOM, not tDOM. They both have Tcl XML APIs of some sort. Apparently, TclDOM is implemented in pure Tcl, while tDOM is some high performance C code and much, much faster. And as of 5.0, OpenACS is already using tDOM for other XML stuff.
Collapse
8: Re: XML-RPC package ready (response to 4)
Posted by Vinod Kurup on
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.