4 Mar
2008
4 Mar
'08
11:05 a.m.
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