27 Aug
2007
27 Aug
'07
8:49 p.m.
Hi Asiri/Catalin,
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(a)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