I have been cranking out the code at pretty fantastic rates the past few days… I am trying to get our document list view buttoned up before I leave today… I am leaving at 5:30 to meet Chuck at South Station… He is coming up for the weekend, and I was hoping that I would have tomorrow off, but I don’t think things are coming together as well as I had hoped (ok, they were pretty unrealistic expectations), so I will probably have to come in for a little while.
XML-RPC is a decent protocol, but it definately has it’s flaws… It is doing the job, however… It is much easier to deal with, as well as more robust than our old proprietary protocol… The support in Java and Mozilla is good, but I am going to rewrite Mozilla’s XmlRpcClient component in C++…. It is currently implemented in JavaScript, including the XML parser! It was even doing Base64 encoding in JavaScript but I shit out a component to do that in C++… Man, what a mess… It was doing type checking and string addition every time it added a base64 value to the return string…. what a mess… It is totally fast now, and I got to reuse some of the Base64 code already in mozilla for MIME stuff, so I didn’t have to duplicate work….
So what do you think: XML-RPC or SOAP?
I have an academic understanding of some of SOAP, but I haven’t worked with it…. In looking at the two standards, though, it seems that SOAP is bloating much more than necessary for most RPC applications… SOAP was originally XML-RPC + Namespaces, but not it has been horribly extended…
Some of the feature creep has been warranted, but some of it has been unnecessary (enums).
SOAP might be worth more of a look once the specification settles a bit, but for the time being, unless you REALLY need some feature of SOAP that is really hard to implement via XML-RPC, XML-RPC is the way to go…
Then again, my RPC needs are pretty straightforward (call a method, get a return value), so take that FWIW…