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.
Catalin > >> 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
