Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Subject: RE: [Vote] The right container for 2.2
Date: Fri, 19 Mar 2004 14:26:42 +0100
Organization: S&N AG
MIME-Version: 1.0
In-Reply-To: <970A1852-799F-11D8-B32C-000393C27E0C@betaversion.org>
Thread-Index: AcQNq5hc5HkIOuhTT7Ge5bOj4eu5KQAChs0Q
Message-ID: <OFBB02B8F5.81F0375F-ONC1256E5C.00491FDE@sundn.de>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks for the info.

Now I think we will wait with reverting to ECM. Perhaps it makes
sense to first look at your stuff and see how/if it fits and then
do the appropriate work.

Carsten=20

> -----Original Message-----
> From: Pier Fumagalli [mailto:pier@betaversion.org]=20
> Sent: Friday, March 19, 2004 1:19 PM
> To: dev@cocoon.apache.org
> Subject: Re: [Vote] The right container for 2.2
>=20
> +1 for reverting to ECM right now to have a more stable 2.2 base.
>=20
> On 19 Mar 2004, at 10:03, Carsten Ziegeler wrote:
> > Reinhard P=F6tz wrote:
> >>
> >> +1 as this move shouldn't have any impact to Pier's=20
> container *if* we
> >> decide to use it.
>=20
> Will you guys stop spoiling surprises? :-( :-(
>=20
> > Yes, "*if*" is a good remark here.
>=20
> As a word of warning to the ones listening, I am developing a=20
> container implementing "blocks" in a way very-very-very=20
> similar to the Cocoon requirements to be used in my=20
> employer's web back-end (front end will be Cocoon 2.1 as-is).
>=20
> As I explained to some of you, I'm actively developing it for=20
> VNU right now, but I am shooting for a more "stable" release=20
> with implemented blocks for sometimes next week... More news=20
> to follow...
>=20
> >> It's up to you Carsten if you want to risk that ECM is=20
> replaced again=20
> >> in a few weeks.
> >
> > Thanks :) - But I don't have any problem with this.
>=20
> I think that if we want to implement "real" blocks, and if=20
> the container supports "real" blocks, the core problem won't=20
> be the container itself, but the infra-blocks contracts,=20
> especially related to class loading core in the VM and lookup=20
> issues as each block could be seen as a different "isolates".
>=20
> And those issues would be reflected on the implementation of=20
> the blocks, and their components, themselves...
>=20
> At least, that's my thought, and as I always say, I might be=20
> completely wrong.
>=20
> 	Pier
>=20