cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [RT] Simplifying component handling
Date Wed, 04 Jan 2006 13:28:13 GMT
Hash: SHA1

On Wed, 4 Jan 2006, Carsten Ziegeler wrote:

> Date: Wed, 04 Jan 2006 12:36:19 +0100
> From: Carsten Ziegeler <>
> Reply-To:
> To:
> Subject: Re: [RT] Simplifying component handling
> Sylvain Wallez wrote:
>> Guys, remember the real-blocks container story? Two reasons led to the
>> choice of OSGi: there are existing implementations, and it stopped the
>> endless discussions about what the container API should be.
>> We have exactly the same here. "why not this or that" and "I don't need
>> it but you can implement it" lead nowhere. NIH syndrome at work.
>> Cocoon's goal is not about containers, but about components. Cocoon was
>> one of the first component-oriented frameworks, but times have changed!
> Yes, so why not throwing ECM++ away and use an existing container? We
> can provide an Avalon compatibility bridge for nearly any existing
> container.

ATM I do see this as a valuable way to go.

- - Declare our legacy Avalon components being the "bridged" ones
- - Start using an existing container
- - Migrate the legacy stuff over

> I don't want to build an own container in Cocoon, but
> currently using an existing one for the core has been veto'd several
> times, so we have to stick with ECM++. But making this more useful is
> also veto'd. Hmm. And as we can't come up with a good solution (being it
> using an existing container or improving our own), we simply tell the
> users to use whatever they think is right - as we don't know it.

That's a deadlock.

- -- 
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message