On Sep 5, 2007, at 8:56 AM, Catalin Hritcu wrote: > Hi Vincent, > > On 9/5/07, Vincent Massol <[EMAIL PROTECTED]> wrote: >> >> On Sep 4, 2007, at 10:55 PM, Catalin Hritcu wrote: >> >>> Hi, >>> >>> On 9/4/07, Catalin Hritcu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
