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

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
>
_______________________________________________
devs mailing list
devs at xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs