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

Sergio Carvalho wrote:

I am quite troubled by the fact that you took the ideas that we launched last November, put them to use in a project incompatible with PEAR (license-wise) and now based on that project results, refuse to accept the package into PEAR. Oh, and by the way you didn't consult me either (not that I think you should have).

What the hell? Let's just say the paragraph I quote is a perfect example of the missing spirit of collaboration. Sergio, I don't have time for flame wars. Let me just say that everything in the previous paragraph is patently false, and reminds me of the kind of mud-slinging going on in the American political arena. The PHP License is compatible with PEAR, and the only reason I've been using Chiara_XML_RPC5 is because XML_RPC2 which you proposed was both not finished, and simply was not useful for a real-world application. I needed a php5-based xml-rpc implementation for Chiara_PEAR_Server, and none existed. If you check the archives, you'll see that I wrote the original code for XML_RPC5 (called as such because it was php5-based, and not a rewrite of XML_RPC, which would justify XML_RPC2, but that doesn't matter to me). It was you who took the ideas and went in a direction that did not reflect a useful design for the real-world applications that I and others use. Also, to call Chiara_XML_RPC5 non-OO procedural code is patently false, I challenge you to find a single function or procedural design element. It is in fact fully OO, much smaller, and much leaner design while retaining full functionality. Also, in my benchmarking of PEAR, even with a cache like Zend Optimizer shows that the most expensive operation in PHP is require_once (yes, even with a stat cache, because the first time is not cached, and the inefficiency is per request, not within a request). Your code has more than 5 times the number of files that Chiara_XML_RPC5, and in addition, each class declaration takes much more time and memory than a method declaration. A single-method class should be a part of a parent class, or re-factored to work with other classes. You require people wishing to process values sent and returned from XML_RPC to create a huge number of objects. This will substantially increase memory usage, which is another unnecessary inefficiency. I think XML_RPC2 would be very valuable, I am voting against your code, not the idea. I voted -1 because I don't feel that as it stands, XML_RPC2 is a good design. The call for votes was too early. Your XML_RPC2_Value_* is totally unnecessary, and does not make it simpler to use the class, or easier to debug (try var_dump()ing such a monster as opposed to a PHP array). Chiara_XML_RPC5 uses the native values from PHP without any trouble at all. 99% of xml-rpc implementations don't need the obscure base64 and iso9660 types, everything else translates directly into PHP arrays, strings, boolean, and integers, and gettype() works just fine with these. The system Chiara_XML_RPC5 uses is similar to the way that the xmlrpc-epi extension (which is procedural) adjusts values for those who do need the base64/iso9660 types. The element that defines good OO design is that you are not forced to understand the internals of an implementation in order to use it. Instead, all data within an object should be accessible through API calls. The method of data distribution does not make code procedural - an array wrapped in an object is still an array, the question is do you want to waste time wrapping it or not. Sometimes you do, when the data must be manipulated directly, but in the case of xml-rpc, data is only transported, and is represented *in the standard* as arrays/structs/integer/bool/string, and so true object-orientation would represent these objects as their PHP equivalents (array, associative array, integer, boolean, string). Sorry, but I voted -1 because I do not want to see another sub-standard implementation of XML_RPC in PEAR. Others may differ with my opinion, and I respect that. I will bow to the majority will, I just wish it didn't have to come to this. Greg