New subject: [xwiki-devs] XWiki XMLRPC (Please reply to this message for discussion)

4 Mar 2008

Dear all,

I am working on adding XWikiObject-editing support to XEclipse and  
this requires some kind of re-engineering on the server side, so I  
writing this mail to discuss about some issues.

 From my understanding, please correct me if I'm wrong, the current  
XMLRPC API defined in com.xpn.xwiki.xmlrpc.ConfluenceRpcHandler
exposes several methods for accessing to XWiki functionalities using a  
set of domain objects that mimic the ones defined in the CodeHaus'  
SWIZZLE-Confluence package (com.xpn.xwiki.xmlrpc.model.* and  
com.xpn.xwiki.xmlrpc.model.swizzle.*).

On the client (XEclipse) side the CodeHaus' SWIZZLE-Confluence project  
(though slighty patched) is used in order to communicate with the  
XMLRPC extension.

Things are fine because the APIs and the domain objects defined on  
both the server and the client side are basically the same (there is  
some kind of code duplication between XWiki and SWIZZLE).

Now, in order to handle XWikiObjects I am in need of adding both APIs  
for accessing the functionality (getObjects, putObject, etc.) and the  
domain objects for modeling XWikiObjects.

Actually some of the APIs are already implemented on the server side  
(e.g, Object[] ConfluenceRpcHandler.getObjects(String token, String  
pageId, String className), actually returning Comment objects(?!?!)).  
However they return unstructured data, while the other methods return  
incapsulated data in objects where the user can conveniently call  
accessor methods (e.g. Page.getSpace(), Page.getVersion(), etc.). So  
domain objects and client side interfaces for the new methods are  
still missing.

 From my understanding I see the following alternatives:

1) Extend the current confluence compatible API and add the needed API  
and domain objects in the core. This has the implication that those  
extensions should be provided on the client side as well:

    1.1) We fork the SWIZZLE-Confluence project and add those  
extensions. (Note that this should almost be the way it is done now  
because the XEclipse embedded xmlrpc client is a patched version of  
the original CodeHaus' SWIZZLE-Confluence)

    1.2) We add the extensions in the SWIZZLE-Confluence project on  
the current Codehaus' codebase.

2) We refactor the XMLRPC API by implementing the current XWiki Object  
Model and we provide a facade for making CodeHaus' SWIZZLE-Confluence  
interacting with XWiki seamlessly.

3) ... Add your own if I have missed something.

 From my point of view and understanding (again, please correct me if  
I am wrong), there is an architectural problem in the current  
implementation. It seems to me that we are providing a facade for  
accessing Confluence using XWiki interfaces instead of doing the  
opposite. This is not completely correct since we are leveraging the  
SWIZZLE API for modeling the "common part" between the XWiki and the  
Confluence models... But still, we need extensions because XWiki has  
more stuff with respect to Confluence.

Looking at the solutions:

1.1) Is a viable way that preserves most of the infrastructure already  
implemented. However we need to fork in order to make all our  
extensions freely and independently. A way for doing this might be to  
create an XMLRPC component by getting the com.xpn.xwiki.xmlrpc.* out  
of the core, and providing two jars: com.xpn.xwiki.xmlrpc.client (or  
whatever) with the interfaces that the client can use (i.e., something  
like the jar currently embedded in XEclipse) and com.xpn.xwiki.xmlrpc  
(or whatever) with the server implementation.

1.2) Is weird and not feasible. Weird because I don't see how and why  
a getObjects() method and a XWikiObject class should be present in a  
Confluence API, and infeasible because we don't have access and we  
don't manage the CodeHaus' SWIZZLE-Confluence project.

2) Is a solution that requires more work and that gives the maximum  
flexibility, but since there has been already an implementation that  
has settled on the principle "the Confluence API is ok for accessing  
XWiki", part of this solution is already implemented and it's fine so  
we fall back on 1.1

3) ... Add your consideration here.

To conclude I think that 1.1 is the best way to proceed... Provided  
that we are sure that the Confluence API is really OK for accessing  
XWiki (with respect to the "common" parts). Otherwise 2 should be the  
way to go.

Maybe the "compatibility" principle deserves some additional analysis  
in order to be more confident that in the future we will not be locked  
in a limited interface when dealing, for example, with simple Pages or  
Spaces.

WDYT?

Cheers,
Fabio

P.S.: Or we might get rid of XMLRPC and go fully REST... But maybe  
this could be another nice independent extension :)