The main difference is that the interface is function based, rather than object based.

On the downside, being php 4 compat, it cannot throw exceptions when remote invocation fails.

On the upside, it offers the option to probe the remote server for importing its “xmlrpc namespace” either at runtime (slow, as it adds extra xmlrpc calls to system.listmethods and system.describeMethod) or at design time, in which case it works as a php code generator (works if the server api is not subject to frequent changes)

You are right, both projects have been around for about the same amount of time with comparable functionality. They both made their first releases around the same time, with XML_RPC2 in November 2005 and Zend XML-RPC appearing with the first release of the framework a few months later in the following March.

I was a PEAR XML_RPC user and contributed some bug fixes to that a while back. I have also been aware of XML_RPC2 since its beginning although I have not used it in production. It was only declared stable last month, although it had not changed much in very long time before then.

The Zend version is a bit simpler, has excellent PHPUnit test coverage, a more dynamic server proxy object, and avoids the static functions and cURL extension requirement. Unlike XML_RPC2, ZF is not yet declared stable. PEAR XML_RPC2 client in turn has functional tests in PHPT, offers similar capabilities, and adds Cache_Light integration. Both are fine choices depending on the needs and preferences of the developer.

Mike

I committed it a few weeks ago and it has been available since version 0.7.

Mike

I’ve implemented a custom RPC protocol for fun in my spare time (years ago) and the first thing I did was getting rid of such call() methods and directly propagated the methods into objects. Unfortunately this was PHP4 so it was a mess using eval(), anyway.