Re: [PEPr] Comment on XML::XML_RPC2

Greg and Davey, Greg Beaver wrote:

Davey wrote: [snip]

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.

Sergio: this is part of what I've been railing about :). The amount of debugging triples. It's very important to limit the number of routes that Murphy's Law can appear in the user's code. It's far easier to control bugs in the XML_RPC2 package.

Let me get all ideas straightened out before touching the code again... Right now, from the input received, I envision two usage scenarios: 1) Provide the server with a class exposing callable procedures as public static methods. 2) Provide the server with an instance whose public methods will be exposed, regardless of being static or not. Scenario 1 is what I'd advise if you are designing the web service from scratch. It matches perfectly to the procedural interface of XML-RPC, converting it to OO. If you're writing the web service against a standardized API, then you start with this frontend class, and have it attach to your OO architecture. I'll emphasize the need for procedural<->OO conversion with an example from the Blogger API blogger.newPost procedure: http://www.blogger.com/developers/api/1_docs/xmlrpc_newPost.html The arguments don't match an OO design, as the blogid and username are keys (not memory references) to the object instances. The frontend method will create the respective Blog and User objects from the keys, and call the respective Blog::newPost method using the OO architecture. The method can be static, as it is nothing more than a procedure. Moreover, the MethodHandler subclass serves only to aggregate these methods in order to present an external API. In Patterns lingo, the MethodHandler class poses a procedural Façade of the OO API. Scenario 2 is the one I'm less familiar with. It was proposed by Greg, as a quick hack for exposing an API. You just grab an object instance, and have all of its methods exposed. I recognize I made a design error when requiring this class must inherit from InstanceMethodHandler. The requisite doesn't match with the RAD-style Greg sugested. However, in this thread I proposed a different approach to scenario 2: a DelegationMethodHandler. A DelegationMethodHandler would expose the methods from *another* object instance. In the example I gave, it'd be something like: $foo = new Foo(); $server = new XML_RPC2_Server(

              new XML_RPC2_DelegationMethodHandler($foo));

for exposing the methods of the existing Foo instance $foo. Now, my doubt arises when you mention interfaces in this context. I don't need Foo to implement any interface. It just needs to have its methods docblock-comented and that's enough. In terms of RAD, this is even better. Quickly exposing any existing class requires no change whatsoever to the existing code. Greg and Davey: Does DelegationMethodHandler fit your needs for scenario 2? Davey, most of this reasoning applies to the design of a common RPC interface. This presentation doesn't attack two aspects: 1) Non-procedural interfaces for SOAP: SOAP is designed to allow real OO calls, even if I never saw it used in my limited experience. Are all SOAP calls procedural, like in XML-RPC, or are there OO calls (call method bar *on instance foo*?) 2) Limited method vocabulary: REST interfaces limit the vocabulary to HTTP verbs, so REST is a kind of special RPC that pre-defines the callable methods. Cheers, Sérgio