[pLog-svn] xmlrpc file change?

[Oscar Renalias]

The idea is interesting, and I think it would be good to make it  
easier to add new APIs. It would even be "proper" programming, by  
decoupling the server class from the interfaces/APIs it implements so  
I say go ahead with it :-)

But I'm not so sure about the implementation... I don't like using  
functions rather than classes very much, and I don't like messing  
with $GLOBALS unless there really is no other option.

One thing we could do is modify the XMLRPC server library (which is  
not maintained anymore anyway) and add support for method calls  
outside $this, so instead of this:

"blogger.newPost"  => "this:newPost"

We'd have this:

"blogger.newPost"  => "BloggerAPI:newPost",

The method-calling logic is implemented starting at line 340 of  
IXR_Library.lib.php, I don't think it's too difficult to modify it so  
that it parses the "class:method" line, then does "new $class" and  
finally "$class->$method". It needs a bit more work than if we move  
to the function-based approach but I think it's cleaner (at least  
from my OOP point of view, anyway)

Even with this I wouldn't know how to get rid of $GLOBALS, unless  
every API implements a method called "register" or something that  
would return all the XMLRPC methods supported in an array.

Regarding the atom api, the 'atom' plugin already implements it (at  
least Atom 0.3) Did you mean to reimplement it totally (which is  
quite a bit of work) or just add missing features?

On 4 Jun 2007, at 22:59, Jon Daley wrote:

> Do people have objections to changing the /class/net/xmlrpc/ directory
> like this?
>
> I thought it would be a lot cleaner than this, which is why I  
> started on
> it.
>
> The advantage is that each api is separate from each other, and seems
> easier to add new apis.  But, it didn't end up as clean as I  
> thought it
> would be, so I'd understand if people didn't like it.
>
> I am looking into porting the new gdata api, or maybe the atom api,  
> not
> sure what.