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

[Catalin Hritcu]

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 ?

Catalin


> 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