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

Joshua Eichorn wrote:

Philippe Jausions wrote:

Sergio Carvalho wrote:

Davey Shafik wrote:

I don't see this as being much of an improvement. I want to see something as simple as ext/soap. It should be as close to identical API wise as ext/soap and require no more or less work.

Why would you want to call methods using $proxy->soapCall('methodName', ...) when you can use $proxy->methodName(... . Or why would you want to setup a server doing $server->addFunction ad nauseam when you can just point the server to an interface class? I'd more accept see a wrapper PEAR class over ext/soap which adds catchall use, docblock parsing and Exceptions.

I've got to agree with Sergio, $proxy->methodName(...) is more attractive. The prefixing thing might throw some people off, though. Anyway, the point is whether Sergio's proposed way of doing this better than the ext/soap's. There are certainly ways to wrap things around from one model to the other. AFAICS Sergio's solution is much simpler...

I think your missing something, there is no soapCall method, the soap ext proxies, there is a __SoapCall method which can used in circumstances where you want to do something custom, which is always a good design. Simple general usage while still allowing other custom usage.

First __SoapCall and other __*() methods are used for low-level access to some feature of the extension, therefore, this is going around the simple API that some people claim is not acheived with Sergio's package (beside maybe the XML_RPC_Value_* classes.). AFAICS, __SoapCall() is to work around SOAP-related issues, but my knowledge in both SOAP and XML-RPC is not enough to make. The addFunction() seems ill-fitted in OOP, setClass() is unessecary with XML_RPC2. So, I don't really see the problem of convergence between xmlrpci and XML_RPC2. -Philippe