Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <43BBA7E3.3000302@apache.org>
Date: Wed, 04 Jan 2006 11:48:03 +0100
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
References: <A955EA1F8FE31749AEC8C998082F6C7C41A8B7@hai01.hippo.local>
  <43B9164F.5080201@apache.org> <43B95C08.8010602@dslextreme.com>
 <7557e99f0601020933xe119a58j588921935798ba63@mail.gmail.com>
 <43BA239A.5000200@apache.org> <43BA403D.7000701@apache.org>
 <43BA46C5.3020409@apache.org> <43BA4B75.7040908@apache.org>
 <Pine.LNX.4.64.0601032202150.8158@lapgp.otego.com>
 <43BB82F8.5000808@apache.org>
In-Reply-To: <43BB82F8.5000808@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Sylvain Wallez wrote:
> I asked Carsten why he doesn't want to use the bridge that _he_ wrote, 
> and would love to have his answer. Carsten?
> 
Now all this comparing of the things Apple did with our situation is
missing imho a big difference: Apple decided that their next OS (MacOS
X) should have this and that feature and *then* they thought about a
possible bridge for old stuff. So first they had a plan on what to build
next (without taking old stuff into consideration). Even more important
the bridge is a connection from the new stuff to the old one.

Currently we are discussing the opposite! We say, we have this nice
bridge that allows the user to use anything (Spring, Pico, Hivemind) she
likes and this bridge is a connection from our old stuff (we want to get
rid off btw) to new stuff. So, we don't have a clear plan on what the
new version should be and just leave it to the user. This would be like
if Apple had said, oh, we still use MacOS 9 and provide "bridges" for
windows, linux and AmigaOS. See the difference?

And this is why I don't want to use the bridge in general. It's the
wrong way. The bridge is nice if you want to use Spring etc. with Cocoon
and want a tighter integration. But with the bridges the core will never
change, it will still be ECM++. And the current bridge has some other
problems, it does not provide access to everything required and I think
it might have a performance problem if used the wrong way.

Now, actually, I wanted to have constructor injection and more
simplifications to make working with the portal block easier. As the
portal block in theory has no real connections to cocoon - it's a set of
components triggered by a generator - I think I'll use a different
approach there, like embedding Spring directly into the generator and
building the whole portal on top of Spring without using anything of
Avalon. Other portal relevant projects are using Spring anyways, so it
might make sense to go into that direction as well. But I fear this
approach will not work for other blocks.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/