Re: [PEPr] Comment on XML::XML_RPC2

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.

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

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?

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.

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.

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...)

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. 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

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.

- Davey