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
