On Aug 27, 2007, at 8:36 PM, Asiri Rathnayake wrote:
Hi All,
I did a preliminary analysis about swizzle and the possibility of using it withing xeclipse rather than using raw xmlrpc invocations (this is how we currently communicate with server - raw xmlrpc).
As i understood (correct me if i'm wrong) swizzle is a nice wrapper for the raw xmlrpcs and handles a lot of low level information such as object serialization, de-serialization, exception handling and session management. Apart from that, it has it's own domain object model (pages, spaces, attachments and so and so on).
I really feel guilty about not looking into swizzle little earlier because currently XEclipse is tightly coupled into our own domain model. In other words, we have implemented our own wrappers for raw xmlrpcs within XEclipse which pretty much resembles swizzle (but not that powerful).
In my opinion, changing XEclipse to use swizzle requires a lot of changes into XEclipse code. This is primarily because XEclipse' functionality is tightly bound to the domain model we developed for XEclipse.
For an example, in XEclipse we have the hierarchy;
Connection -> Space -> Page
(A single connection for a session, many spaces under a connection and pages under spaces)
A lot of code in XEclipse depends on this model. But such a model is not present in swizzle.
I was just having a thought, what's wrong if XEclipse continue to use raw xmlrpcs rather than switching to swizzle ? what sort of problems / disadvantages this would imply ?
Pros:
* A single way for all xwiki clients to connect to XWiki servers
* Less maintenance, less documentation, less work in general since someone else is developing swizzle :). This point only is huge.
* Possibility to add new actions for XWiki-specific stuff missing in swizzle (I haven't checked but Catalin says it's extensible)
Cons:
* Need to refactor current XEclipse implementation to use Swizzle.
* If swizzle goes away or is abandonned then it'll be bad for xwiki and we'd need to support it/reintegrate it. Actually this is a point that is bothering me Catalin. I think we'd need our own object model and expose that as a component and then provide a default implementation using swizzle behind the hood. Same as what we're doing for everything. This will also make the API seamless WRT extra APIs we have for xwiki (like getting objects, etc).
So IMO:
* We shouldn't use swizzle directly
* We should develop our own client side Java Objects and API *interface* for people interacting with XWiki remotely.
- That API should be independent of the protocol used.
- A default implementation should be done using swizzle. It'll be mostly empty and only call out swizzle objects/swizzle APIs
* XEClipse should be refactored to use this API
* This API should be developed using components and using the new org.xwiki namespace.
WDYT?
And Catalin, by "moving to swizzle-confluence" did you mean that we should make XEclipse use swizzle or did you mean that the back-end API would change ?
I think he meant "XEclipse uses swizzle".
Thanks
-Vincent
On 8/27/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote: Hello,
Until now I have refrained from making API breaking changes in XML-RPC
in order to keep compatibility with XEclipse. However, these changes
are necessary and cannot be delayed forever, so after the release of
XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need
to be moved to swizzle-confluence. I volunteer to make this change
happen in the XEclipse trunk once XEclipse 1.0M1 is released.
To sum things up:
- XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the
remaining releases on the 1.1 branch)
- XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later
WDYT ?
Catalin