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

Greg Beaver wrote: > 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. My sincerest apologies. I have confused Chiara with Crtx. Forget I said what I said. It was out of line and impolite. > 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. although calling in the US political arena might be enough for me to pull a Godwin on you :-) > 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'm curious on your benchmarks. Sincerely curious. My experience is the opposite. At least on linux, the OS caches the stat info. You do incur a penalty the first time you check a file, but if the info doesn't leave the disk buffer, you pay nothing on subsequent requests. As for actually reading the file, it only happens on changes, for accelerated servers. I never looked at memory usage. However, PHP objects are, internally, little more than glorified associative arrays. I seriously doubt I'm incuring in heavy memory usage. Just to be on the safe side, I ran XML_RPC2 through xdebug to have a look on the timings. My original impressions hold true. Given that your position is prevalent among PHP developers, I'll post it in a separate e-mail to the list. I hope its an eye opener. > 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. Out of curiosity, how do you make a call with a base64 parameter? or a date parameter? With XML_RPC2 it's something like: $client->foo(new XML_RPC2_Value_Base64('somestring')); $client->bar(new XML_RPC2_Value_Datetime($timestamp)); It's not acceptable to assume that 99% of implementations don't need base64 or datetime types. Heck, Blogging APIs use the datetime type, and they certainly make more than 1% of XML-RPC uses. Moreover, xml-rpc has a spec. You write for the spec, not for the subset you personally like. > 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. Look at the examples. Does it look like its exposing the internals? > Instead, all data within an object should be accessible through API > calls. It is. > 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). I may need to refer to the actual type. Namely, when automatic mapping can't work: - PHP Arrays to either XML-RPC struct or XML-RPC array. - PHP Strings to either XML-RPC string or XML-RPC base64 string. - PHP ints to either XML-RPC int or XML-RPC dateTime. In these cases, you must encode the native type first: - The PHP array has numeric, sequencial keys, starting at 0 or 1, but should be encoded as an XML-RPC struct (i.e. looks like an xml-rpc array, but is in fact a struct). - The string must be encoded as base64 - The int represents not an int but a dateTime. Who do you ask to encode? In proper OO, you ask the respective type. That's why the type classes exist. They should exist, unless you give me an excellent reason not to. Performance is an excellent reason, but I won't take anything but cold numbers. In my benchmarks, XML_RPC_Value_* accounts for 1% of request execution time. I'll post the benchmarks in a separate email. > 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. It won't come to this, because I won't accept the package in PEAR if you won't use it. You maintain the main PEAR XML-RPC clients, and I don't have the right to make you use something you disagree with. I wrote the package primarily for use within my company, don't mind it being released in PEAR, but make no big deal whether it is released or not. I am, nevertheless, completely sure you are wrong in your views about complexity and performance. In these occasions, I wish I could have an in-person conversation with a whiteboard in front of us, to pour some sense into you. Premature optimization is indeed the worst of a programmer's sins. > > Greg Sérgio