Re: XML_RPC_Easy (pre)proposal

Greg Beaver wrote:

Fabien MARTY wrote:

Hi,

I have a feeling you haven't been following the pear-dev list much over the past year, so I will bring you up to speed. :) XML_RPC2 is what you're looking for, but it is actually easier than the method you propose since it uses the reflection API to generate the method list.

I know XML_RPC2 but the proposal was rejected. And even I read good news about it on this list, there is still no package available and no activity (new proposal...).

This is technically incorrect - it was voted in, and there are two people who have expressed reservations: - Dan Convissor, lead of XML_RPC - Pierre-Alain Joye Pierre wasn't even dissatisfied with the code, only the political process, and wants Dan to review it. Dan agreed. This was last May. He's had long enough, and it's time for the community to step in and override the wishes of two individuals for the greater good. If we don't, it sends a clear message to the outside world what the priorities of PEAR are: "Maintainers of a package have absolute control over any and all future endeavors in PEAR that are somewhat similar to that package, including the ability to not make a decision and kill a package through inaction." I do not want to send that message as it would be both incredibly stupid and not at all useful. :)

I think that PEAR need a "easy & modern" XML/RPC package NOW (and probably an easy SOAP client too). There are two ways : - XML_RPC2, which is a biggest thing because it replaces XML/RPC - XML_RPC_Easy, which is only an little additional layer and which uses and depends on the well tested XML/RPC stuff If XML_RPC2 is available in a few days (weeks ?), I completly agree to drop my proposal. But if there are some big delays again.....

Precisely my point. I would imagine that getting XML_RPC_Simple (better than Easy) into the XML_RPC package would also be up to Dan Convissor, so you're probably going to run into the same issues as XML_RPC2.

PS : I can add the support of the reflection API as an additional way because IMHO it's not a perfect thing when you want to use strong function signature (string, bool, optional int...). PHP "Type Hinting" features are not enough good to do that.

Agreed. XML_RPC2 also extracts data from /** docblocks */ including @param data, and uses this to determine type beyond type hinting. Greg

Services_Webservice will probably also "borrow" or somewhat work with XML_RPC2 for the server-side at least.... I find somewhat ironic that you want to propose a new package to avoid reinvent the wheel ;-) -Philippe