[xwiki-devs] Fwd: Use Swizzle directly or use a facade (was Re: XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT)) - xwiki-devs@xwiki.org

28 Aug 2007

---------- Forwarded message ----------
From: Asiri Rathnayake &lt;asiri.rathnayake(a)gmail.com&gt;
Date: Aug 29, 2007 1:33 AM
Subject: Re: Use Swizzle directly or use a facade (was Re: XEclipse
1.0M1will only work for
xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT))
To: Vincent Massol &lt;vincent(a)massol.net&gt;
Cc: Catalin Hritcu &lt;catalin.hritcu(a)gmail.com&gt;om>, XWiki Dev <
xwiki-dev(a)objectweb.org&gt;gt;, Tharindu Jayasuriya &lt;djtharindu(a)gmail.com&gt;om>, Sergiu
Dumitriu &lt;sergiu.dumitriu(a)gmail.com&gt;

Hi All,

With Catalin's patch we (Catalin & Myself worked together on this) were able
to modify XEclipse to use swizzle underneath. XEclipse - XWiki object model
is still preserved. For an example, IXWikiConnection, IXWikiSpace,
IXWikiPage are all there but they delegate method calls to internal swizzle
implementation rather than handling them ourselves.

Currently we have XEclipse (modified to use swizzle) working against current
xwiki trunk (not commited yet). Once we have make it work with XWiki 1.1,
we'll commit it out (possibly by tomorrow).

Thanks Catalin for all the help.

- Asiri

On 8/28/07, Vincent Massol &lt;vincent(a)massol.net&gt; wrote:
...

 Hi Catalin,

 A new healthy fight! :)

 See below.

 On Aug 27, 2007, at 10:32 PM, Catalin Hritcu wrote:

 [snip]

   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.
  I would not stress this. Actually I already worked quite a lot on
 improving swizzle so far and I think there are many other ways we will
 have to improve swizzle. What is nice about it was having a visible
 working project to start from, rather than implementing it from
 scratch. Having David to "guard" the source is just the cherry on top
 of the cake. 
 You didn't spend even 1% of the time it took to create Swizzle as it
 is today and if you think about how swizzle will evolve in the future
 that percentage drops down to 0.01%. This is why I thought this
 should be stressed out :)

 [snip]

   * If
swizzle goes away or is abandonned then it'll be bad for
 xwiki and we'd
 need to support it/reintegrate it.
  First, swizzle is open source so can't "go away", we can always
 continue to maintain it. 
 That's harder than you think. Radeox went away and are we maintaining
 it? Nope. Of course we can always say that it's because its
 architecture was too limited, etc but had it been maintained its
 architecture could have evolved too. The same would happen with
 swizzle if it goes away IMO. But it's not only an issue of Swizzle
 going away because it's abandoned. Imagine a competitor project
 appears and it's better than swizzle for XWiki. How do we tell all
 our users that they have to redo all their client code. We won't and
 thus we probably won't move to this better project because we have
 standardized on Swizzle.

 It's about having a stable client-side interface.

 I much prefer the approach where we define our model objects (we need
 them anyway on the server so it may even be possible to share some of
 them on the client - Not sure about this but it's a thought) and our
 interfaces and we keep the implementation separate. I'm 100% for
 implementing those interfaces with Swizzle.

 In addition we need to offer a XWiki-specific API so instead of
 offering several remoting APIs I propose we offer only one. Then it's
 up to the implementations to implement them. The confluence
 implementation (using Swizzle) could throw NotImplementedException
 for stuff it doesn't implement so that client code using it will be
 100% confluence-compatible if that's the user's desire. And we would
 be able to have a single unified API that has all the XWiki-specific
 stuff.

  And if it ever goes abandoned how would this
 be any worse than what we have now? Now we have two "little-swizzle"
 implementations one of them was _already_ abandoned, and the other is
 very likely to grow into a full fledged "swizzle". Even if we have to
 maintain one swizzle it's a big gain over having to maintain many. 
 See above.

  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).
  It is true that swizzle provides an implementation but not an
 interface. However, why can't we provide interfaces as part of the
 swizzle project ? Why can't we make swizzle more component-friendly by
 just changing it? Why would we need another XWiki-specific wrapper
 layer? 
 Swizzle is not our project. We could become committers to it of
 course but I assure you it's still going to be 100 times more
 difficult to evolve Swizzle than to evolve XWiki code. For 2 reasons:
 * We "own" XWiki. All committers on XWiki are interested by XWiki only.
 * Swizzle has to stay generic and making a generic change is always
 more difficult than making a specific change. The same applies to the
 fact that Swizzle if confluence-specific.

 Regarding the confluence-specific, it bothers me that the only
 remoting interface we're providing is confluence-specific and has
 confluence written all over. I think we should offer a XWiki-specific
 API and let the user choose the implementation he wants transparently
 (confluence or not).

  One advantage I see of improving swizzle rather
than hiding it away is
 that this way we are guaranteed(!) to stay compatible with confluence
 on the common features. While if you start to develop wrappers on top
 of swizzle that may or may not be the case. 
 We wouldn't loose this feature by using Swizzle as an implementation
 of our API.

   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.
  Why can't interfaces be done inside the swizzle project ? Why should
 we try to hide swizzle away ? 
 See above.

     -  That
API should be independent of the protocol used.
  Swizzle is actually already independent of the protocol used. It could
 work with SOAP as well as XML-RPC if somebody went into the trouble to
 reimplement everything for SOAP. The interface would be the same and a
 client would not be able to tell any difference. 
 Then all the best. We can benefit from that.

     - 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.
  Why can't this be done in an interoperable fashion part of the swizzle
 project ? Why can't the namespace be org.codehaus.swizzle :) ? Isn't
 this "not-made-here" attitude? 
 Yep and that's important IMO (see above). The strategy I'd like to
 have for XWiki from now on is to develop components and provide XWiki
 interface classes. The implementations can be done using whatever
 external frameworks.

   WDYT?
  I think that we have no good reason to hide swizzle away under more
 wrapper layers since _swizzle_is_a_wrapper_itself_, and I think that
 we can solve any modularity/componentization problems inside the
 swizzle project. 
 See above again.

 Let's see what others say.

 Thanks
 -Vincent

_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs