[dokuwiki] Re: jsonRPC Plugin

  • From: Michael Hamann <michael@xxxxxxxxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Mon, 13 Dec 2010 16:44:02 +0100

Hi,

Excerpts from Magnus Wolf's message of 2010-12-13 09:34:47 +0100:
> >> Do all plugins that register for the XML-RPC interface really work in
>   your plugin?  I think at least the error handling won't work, so
>   perhaps just rename that event so plugins can distinguish if they
>   should produce JSON errors or XML-RPC errors.
> 
> >> That download link on the plugin page should point to a zip/tar.gz
>   file that can be installed using the plugin manager
> 
> In my plugin there's  a class called IJR_Error with the method
> "getJson()", so I think it's a clear separation from the XML-RPC.
> During the tests of the plugin I got some Json errors so I think the
> error handling should work.

At https://github.com/mwolf/json-rpc-plugin/blob/master/jsonrpc.php#L93
you are triggering the XMLRPC_CALLBACK_REGISTER event which might be
handled by some plugins that use the XML-RPC error classes instead of
the IJR error classes. I think providing such an event is a good idea,
but you should name it different than the XML-RPC event so plugins have
a chance to use the correct error classes. Apart from that I still
suggest to rename the class defined at
https://github.com/mwolf/json-rpc-plugin/blob/master/jsonrpc.php#L40 to
something like dokuwiki_jsonrpc_server.

I know you have already asked the question if that code should be
integrated in DokuWiki core. As you are in fact duplicating a lot of
code from the XML-RPC server I'm wondering if we should try to move the
common functionality of both classes into a parent or helper or even
make the format (JSON or XML) a parameter and create our own error
classes that can generate both JSON and XML errors? It's a bit difficult
I think. Perhaps we could make the JSON/XML-RPC-server an attribute of
that new class and provide wrapper functions for the functions that were
previously inherited? I don't think there are many plugins that provide
XML-RPC server functionality currently so probably when minor changes
are required for them that shouldn't be a big problem.

I'm suggesting this because the current XML-RPC is far from being
perfect afaik. There are still some events that aren't triggered afaik
and some plugins that do special things during saving like the
discussion plugin are afaik broken. When these things are fixed in one
of the APIs probably exactly the same change would be necessary in the
other implementation. Additionally we would make it easier for plugins
to implement calls for both APIs. What do you think about that? Would it
be possible to do this easily or are there a lot of things that are
different? I don't want to blame you that you've done anything wrong, I
think we who didn't respond to your first request are the ones who
should be blamed for not responding. (Btw. I could also understand if you
don't want to do these changes in DokuWiki core as you have already
created that plugin, if you still think it makes sense we could also
find other people - or I some time - to implement these changes.) Of
course I'm also interested in what the other people here say - should we
follow the way of a complete JSON RPC interface or do you think such an
API gives too much access and thus can only be used in relatively few
cases and does is too much hassle to maintain it just for that single
use - or perhaps we could distinguish read and write access so simple
read access could be enabled by default and used instead of separate
Ajax functions?

> I put the plugin to the root directory of the git repository. Zip or
> tar.gz files can be downloaded from "Downloads" button.
> I also put a plugin.info.txt into the directory.
> 
> I think everything's allright now. If there are any proposals, please
> let me know.

I think that should work now (but I haven't tested it).

Regards,
Michael
-- 
DokuWiki mailing list - more info at
http://www.dokuwiki.org/mailinglist

Other related posts: