Re: [PEPr] Comment on XML::XML_RPC2

Sergio Carvalho wrote:

Davey wrote:

On further inspection, I see quite a number of problems, and have a few ideas :) XML_RPC2_Server::$_methodHandler property is public yet starts with a _... very confusing, choose one or the other ;)

It's public because it needs to be accessed by other classes inside the package, but is prefixed _ to mean hands-off. Package users shouldn't need to meddle with the var.

Then perhaps it needs to be protected and the placing of the variable in the object heirarchy needs to be rethought? It just seems wrong to me.

Also, I don't like that whatever class you want to expose must extend XML_RPC2_Server_MethodHandler... this isn't automated code -> XML-RPC INSHO.

What part of extending isn't automated code? You really should design your remote frontend as an isolated class, so extending XML_RPC2_Server_MethodHandler shouldn't pose a problem. If you really need to directly expose methods from a class integrated in the application hierarchy, use delegation. It's exceedingly easy in PHP: http://www.php.net/manual/en/ref.objaggregation.php

Because I'm lazy, as are most people. Make it possible to just expose any code.

I think that the automation should be as easy with XML_RPC2 as it is with Crtx_SOAP - take any code and expose it. I also think that following the ext/soap API is needed, really. $xml_rpc_server = new XML_RPC2_Server; $xml_rpc_server->setClass('foo');

Why should it be like that? XML_RPC2_Server can only take one method handler, and can't work without one. Why create a state where it can't answer requests, when I can require the method handler to be present at construction time? The proposed API does it like this: $xml_rpc_server = new XML_RPC2_Server(new foo()); Why complicate what is simple?

Its hardly a complication. I think having a unified API across the board is more important than a little complication. Besides, you have to make the server run, and at that point it should check and die.

this will do whatever needs to be done to find the methods in the class and automatically map them to the server via __call() Additionally, by having a special handler, you can mimic the: SoapServer::addFunction() method. I was writing this addFunction handler when I stumbled across the stupid (IMO) extending of XML_RPC2_Server_MethodHandler.

Subclass MethodHandler, and place an addFunction in this subclass. It's very very simple. Take a look at the code of XML_RPC2_Server_StaticMethodHandler. You'll just need to change the behaviour of getMethods, so that it returns the added methods, not the introspected ones.

Bleh.

I think this is a good start, I just think you need to become consistent with ext/soap for this to have any success.

Why? ext/soap makes assumptions valid for SOAP only, and as I exposed above, mimicking it too closely creates design flaws. Do we gain anything my copying the interface of an extension? PEAR can provide its own RPC interface, common to every RPC package.

What assumptions? "Take code. Find public callable methods/functions. Make the callable via RPC" how can that not be applied to all web services?!

I understand that one of the difficulties with XML-RPC is its tendendancy to use foo.bar syntax, which we can't use like: $client->foo.bar(args...); Are you doing $client->foo_bar() ? Or is this the weird $client->test('PEAR_Server') ?? i.e. $client->foo('bar'); ? Personally, I would use the _ to . translation except it might intefere with methods actually called foo_bar, I think a $client->call() for these rarer cases would be preferable.

No need for translation. Just use $proxy->{prefix.postfix}(params...)

I did think about that, just didn't like it. It does work flawlessly however :)

Think about being able to take any piece of code, and exposing it as SOAP or XML-RPC. I envision this: example.com/helloWorld.php?soap // expose it as a SOAP Server (handled by Crtx_SOAP) example.com/helloWorld.php?xmlrpc // expose it as a XML-RPC Server (handled by XML_RPC2) example.com/helloWorld.php?wsdl // show the WSDL for the server (only useful to SOAP, and handled by Crtx_SOAP) example.com/helloWorld.php?docs&wsdl or ?docs&soap // show basic docs (handled by the current server, means types and such are correct)

This fits somewhat strangely to SOAP/XML-RPC but won't fit at all for REST. I think we should aim at being programatically easy to expose an API with any of the supported RPC interfaces, but let URL design up to the user.

This will be something *I* want to write for Cerebral Cortex - as its part of a framework, I can do it. I was just giving you some insight into what my final goal would be :)

i.e. If there's an interface PEAR_RPC_Interface, I can pass an instance of it ($iface) to SOAP: $server = new SOAP_Server($iface) or to XML_RPC2 $server = new XML_RPC2_Server($iface) and then answer requests: $server->run

See, if we work together, I can have Crtx_SOAP do this :)

Anyways, I want it to be this damn easy: 1) Write my code. 2) Use it on my site as a PHP class 3) Decide expose as SOAP/XML-RPC 4) Write 4 lines of code, telling the relevant class what to export 5) Done. I think if you guys (with my help if you want it) mimi ext/soap, I will do the same as I did for ext/soap with Crtx_SOAP

I am really not convinced that ext/soap provides a good across-the-board interface for RPC. We are way better off designing a good interface for PEAR.

The API for ext/soap is very small and non-existant on the part of the client (usually). I don't see how we can better this. Really I can't. I did try to better SoapClient and failed. I can't see any other way to get a better client. - Davey