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