The following content was posted to xml-rpc.com by myself on 2001-07-14, http://www.xmlrpc.com/discuss/msgReader$1778

In my opinion, XML-RPC is superior because of a few points - maybe the following express my feelings best:

• Intuition,


• Openness,


• Standardisation and


• XML

With Intuition I'd like to express the natural feeling of XML-RPC to programmers. Commonly parts of a system are connected by calling procedures which pass data or by passing whole objects. XML-RPC is obviously providing the procedure call way, integrating disparate systems in a very natural way - this could even go so far, that a RPC looks like an ordinary LPC (have a look at Pythons XML-RPC implementation).

Of course we've had this before, but what makes XML-RPC superior is it's openness. If you take a look at the implementations list, XML-RPC is supported by lots of absolutely disparate languages or programming environments. Dave has pointed this out a many times: XML-RPC is doing great for integrating and bringing together systems you've maybe even never heard of before. XML-RPC is able to be a kind-of glue for programming environments, and this is an absolutely great thing! If you work with XML-RPC you feel a kind of freedom never felt before - you can simply develop in your environment, in the way you like it.

One could argue that HTTP-POST already does this job for a long time, but if one ever had to write code that interfaces with an HTTP-form, he knows that doing this kind of thing could feel better. XML-RPC is standardised - so simply take a normal interface description and start coding. No need to reverse-engineer HTTP-forms any longer! Some services/servers out there even support introspection - the server tells you what his interfaces are, so let the fun begin!

Last, but not least, XML-RPC uses XML as marshaling format. In my opinion the one major advantage of XML is, that one can concentrate on the data to be passed instead of fiddling around with byte-order or other encoding related stuff. The programming environment only has to provide one parser, and most of the encoding hazards are gone. If the usages of XML continues to spread as it seems to spread right now, most environments will have decent parsers quite soon - a lot already have!


Maybe none of the ideas listed are really new - but I think they give a very fine combination. And it just feels damn good when you work with it! ;)