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 Vincent, On 9/5/07, Vincent Massol <vincent(a)massol.net> wrote: Tried all of the archive listed there and none of them contains recent emails.

>>> 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