Re: [PEPr] Comment on XML::XML_RPC2

Sergio Carvalho wrote:

Davey wrote:

Sergio Carvalho wrote:

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.

It's because PHP lacks the concept of C 'friend' classes. So, much as in PHP4 we were left with just the _ prefix to signify private, now we're left with _ prefix to signify package-level private. Doesn't bother me.

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.

XML_RPC2 delegates the introspection work to XML_RPC2_MethodHandler classes. This delegation design was the result of different perspectives I and Greg had about how to decide which methods to expose. The end result is that introspection mechanisms are pluggable. You can add to the package MethodHanlder classes that expose methods through any mechanism you can think of. One of them is possibly exposing methods from an existing class. So, this question is not a stumbling block. The design accomodates new MethodHandlers as needed. Just go and write one. It's under 50 lines of documented 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.

Please explain to me the advantage of: 1) Unifying under ext/soap API, versus 2) Unifying under an API we design now.

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.

Bleh?! Care to elaborate?

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'll pick an example then: http://www.php.net/manual/en/function.soapfault-soapfault.php This is different from XML-RPC faults. There are lots more. You're just not willing to look for them.

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

You can actually set the prefix for the client class, although it's not documented, because I want the prefix to be settable via constructor. That solves the beauty factor, and is much better than translation.

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

It might be an interesting goal to create *using* the RPC packages, but it's an overshoot for the basic XML-RPC and SOAP-RPC packages.

My point entirely ;)

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

And we can easily get XML_RPC2 to do this. I'm all for defining standard interfaces for the RPC steps: 1) Server introspection 2) Server execution 3) Server Exception hierarchy 4) Client construction 5) Client remote method calling 6) Client Exception hierarchy

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.

Take it from another perspective. Sit down, design an API that would be protocol independent, and *then* see if it is identical to ext/soap. Check advantages and flaws of both approaches. I think you're too stuck in the ext/soap mindset, and unable to think outside of that context. Sérgio

My biggest issue is the class extending, for the simple reason that you need to extend different classes for SOAP/XML-RPC/REST and you can only extend *one*. So you need to write three different classes all of a sudden one that extends a class for each types introspection. Introspection should have no effects/changes on the code itself, it should be self contained. With that thought in mind, your ideas just won't work in that "one API fits all" strategy. We would need to write the introspection both for server and client completely independant of the web service. Now, I can modify *my* code to introspect to a WSDL-like data structure pretty easily (heck, right now it goes to WSDL and then is parsed into that data structure) which contains all the information needed: * Class Name * Method Names * Method Arguments * Method Return values * Documentation I've put in all the ground work already, for the most part at least. The fact that WSDL is XML, means its implementation non-specific, and therefore could be used as an internal representation for a web service. - Davey