Re: Re: [PEPr] +1 for XML::XML_RPC2

Sergio Carvalho wrote:

Joshua Eichorn wrote:

Joshua Eichorn (http://pear.php.net/user/jeichorn) has voted +1 on the proposal for XML::XML_RPC2. Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=172 Vote information: http://pear.php.net/pepr/pepr-vote-show.php?id=172&handle=jeichorn This vote is conditional. The condition is: I'm concerned that your punting the integration work with the xmlrpc extension. Especially since there is work happening on xmlrpci which provides and OO api to xmlrpc. Can you at least do a review of the extension apis to see how integrating them will affect your design, and also note the differences in your api from xmlrpci.

The package design was thought out to use the 'old' xmlrpc extension. xmplrci follows the xmlrpc extension close enough that integration shouldn't be a problem. xmlprci, however, is still poorly documented -- the only docs I've found are the code itself. The only problem is that I won't have time to write the Backend for another couple of weeks. The package is fully functional now. If your question is speed benchmarking of the PHP backend against a native one, I can write a few test cases, using xmlrpci directly so it can be compared. It would be good to see the benchmarks, but this is also an area where im not sure that huge api differences from say ext/xmlrpci or etc/soap makes a lot of sense. I would imagine an additive approach ontop of say the same very simple api as etc/SOAP would be great.

I'm also concerned about forcing docblock documentation to export a class. I think there should be an api to set what your going to export that can be optionally used instead of adding the docblock params.

XML-RPC requires at least the method signatures to be introspectable. Being PHP dynamically typed, this information may not be present in the actual code. Docblock seems the next logical step for looking for this info -- people should be documenting the class anyhow. This docblock-extracting behaviour is implemented by XML_RPC2_Server_Method. I imagine I can redesign the XML_RPC2_Server_Method subtree so that you can choose which introspection mechanism you wish to use. That'll take some time, though. I'm imaging the equivalent of: http://us2.php.net/manual/en/function.soap-soapserver-addfunction.php

In most cases introspection is fine but sometimes some other sort of magic is needed.

Also for something like xmlrpc It would be good to see at least some sort of compatiability testing goals with implementations in other languages since thats generally the purpose of using xml based rpc.

It is in the package, already. The unit tests test against the python implementation. I chose python because its implementation is quite well tested, and exists on multiple platforms. I chose not to add more to avoid creating lots of dependencies on the available languages for the unit tests themselves. Thats fine I just didn't see it, It would be handy on these proposals to have an overview page which says things like this exists so the reviewer doesn't have to read everyline of code to find out whats tested.

Your also not following the page docblock standards and some other areas where your not following the coding standards, but thats not a big concern.

I'll look into the page docblocks. Any more blatant CS failures? the rfc is: http://pear.php.net/pepr/pepr-proposal-show.php?id=128

the only other big one i noticed was no ( in require_once but i think someone else posted some comments about this.

This is a conditional vote to summarize: Add an api for setting up a server without introspection Add extension support or at least review how doing that will affect your design, especially from a speed aspect. I would also really like to see a compat test against the spec testsuite if there is one and if not at least a basic test against another language's xmlrpc implementation.

-josh