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

Wed Sep 5 08:43:05 CEST 2007

On Sep 4, 2007, at 10:55 PM, Catalin Hritcu wrote:

> Hi,
>
> On 9/4/07, Catalin Hritcu <catalin.hritcu at gmail.com> wrote:
>> Hello Vincent,
>>
>> I thought more about this and I think you are right, we should use a
>> facade. I will implement this in the following days.
>>
> 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 ?

Sure, see http://www.xwiki.org/xwiki/bin/view/Community/MailingLists :)

Thanks
-Vincent

>> On 8/28/07, Vincent Massol <vincent at 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
>>>

_______________________________________________
devs mailing list
devs at xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs