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

Vincent Massol vincent at massol.net
Wed Sep 5 09:23:03 CEST 2007 

On Sep 5, 2007, at 8:56 AM, Catalin Hritcu wrote:

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

I tested the Nabble one before sending this email... ;)

http://www.nabble.com/XWiki-f2563.html

I tried gmane but it's down right now.

As for our own archives I think they're archived only once a week or  
something like that. For example the dev one has all mails till the  
28th of August.

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

More information about the devs mailing list