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.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
