Re: [PEPr] Comment on XML::XML_RPC2

Sergio Carvalho wrote:

Greg and Davey: Does DelegationMethodHandler fit your needs for scenario 2?

Yes. Sergio, thanks for being so patient - I know dealing with changes is stressful. :)

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.

Sergio: the main reason I prefer an OO interface for the actual real-life XML_RPC server I'm working on for PEAR_Server is not because of OO features like encapsulation and inheritance, but because I'm lazy :). I don't want to duplicate code for each instance, or have to use a special "static constructor" in every method. The server needs to use a backend object for accessing data abstractly, as well as interact with the actual server code. I would need to add setup code to the start of every method that really should be handled in a constructor. I could actually simulate OO using class variables (no $this), but that seems a bit clunky, i.e. instead of: $frontend = new PEAR_Server_Frontend($server, $backend); $server->setFrontend($frontend); $server->run(); and inside run(): $server->_backend->$method() and using $this->_server, $this->_backend, we'd have PEAR_Server_Frontend::setup($server, $backend); $server->setFrontend('PEAR_Server_Frontend'); $server->run(); and self::$_server, self::$_backend This does work, and so I suppose it could be done, but it seems odd to simulate OO when OO is much more straightforward. The protocol does not care what the function is called from, it only expects that input is received and output is spit out. There is no inherently functional interface, it's only inherently simple. Greg