Sorry for the reposting but I forgot to add Catalin Hritcu to the CC list. Please use this message for the discussion so he will be included in the loop.
Thanks. P.S.: Stéphane this might be an use case for your point in http://arkub.net/xwiki/bin/view/Blog/Farewell_SMTP :) [- Original message follows -----------------------------------------] 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 am 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
