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

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: > QûX¶Á¾LË > ë^Ö_`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. > 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. > 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. > 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? > > 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. >