Re: [xwiki-devs] 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))

Hi, On 9/4/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote: Created http://jira.xwiki.org/jira/browse/XWIKI-1706 for this. Is there any way to reference this discussion from there ? Is there any working archive of the new devs mailing list ?

> On 8/28/07, Vincent Massol <vincent(a)massol.net> 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 >>