cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Date Thu, 22 Jul 2004 06:30:05 GMT
Stefano Mazzocchi wrote:

> Ugo Cei wrote:
>
>> Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
>>
>>> think so too, just needs more wild thinking and somebody doing :-)
>>
>>
>>
>> Since I'm getting more and more bored with my daytime job, I ended up 
>> doing something:
>>
>> http://wiki.apache.org/cocoon/ButterflyManifesto
>>
>> Comments are welcome, flames > /dev/null.
>
>
> Avalon is dying (and I'm personally trying to killing it faster) and 
> this status is hurting us (see the stall of the cocoon 2.2 evolution), 
> so I agree with sentiments here that we must do something.
>
> Changing container is a back-incompatible thing, even if, obviously, 
> we can sandbox existing components into avalon sandbox (as proposed 
> already) so our users should be worried since we care for them.
>
> You are proposing Springs which is a rather simple, bean based, 
> dependency-injection based framework.
>
> Alternatives are:
>
>  - Kernel (written by Pier and designed by Pier and myself)
>  - Merlin
>  - Geronimo Container (also compatible with Springs, from what I hear)
>  - Fortress
>
> My (obviously biased) view is that cocoon is both a production 
> software and a research project, depending on other communities for 
> our critical foundations turned out to be dangerous.
>
> So, the question is: what do we buy in using somebody else's code 
> instead of maintaining our own?
>
> For sure it doesn't save us energy, we already have that container build.
>
> For sure it doesn't increase our ability to innovate, since any 
> changes have to go thru another mail list (which, in the Spring case, 
> is not even ASF controlled).
>
> For sure it doesn't help us with reusability of code, since we reuse 
> libraries over their interfaces (JCP-standardized or not) and wrap 
> them on our own little pipeline abstractions.
>
> Result, I'm -1 on Spring because we can't control it and -0.5 on 
> Merlin/Fortress/Geronimo because they are other communities with other 
> interests.
>
> I say we write our stuff and be done with it once and forever.
>

I think it will be a question of doing it. If Ugo presents a functional 
prototyp of Spring that supports Real Blocks and which can be made 
backwards compatible to 2.1 sitemaps and flowscripts I wouldn't have 
arguments against it :-)

Is anyone else working on an alternative these days? (Carsten, Pier ???)

Some words to the ButterflyManifesto: IMHO it has a clear focus on 
"technical excellence". The point missing (IMHO) is that we have a large 
user base with many, many applications running on Cocoon 2.x. It is very 
important to make their move to Cocoon NG as simple as possible so that 
they don't have to redo all the work. I think this means at least 
support for Sitemaps and Flowscripts and support for existing components 
in a legacy mode.

(I know repeating this over and over again is boring but sometimes I 
have the feeling that this is forgotten ...)

-- 
Reinhard


Mime
View raw message