On Jul 21, 2004, at 7:28 PM, Stefano Mazzocchi wrote:
Ugo Cei wrote:
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.

have you considered picocontainer at all? i would *LOVE* to see the core shuffled about. i want to be able to nest the containment of cocoon's core objects in order to share them between multiple cocoon instances, and being built upon an open container platform helps that a lot.


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
   - Pico/Nanocontainer

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?

I would prefer to see somebody else's code. I think it depends on what one's view of cocoon is.


Is it:
 A) An application framework that you run as a servlet
 B) A set of components that you can integrate into your application

I take view B, and thus the ease with which Cocoon can be integrated into larger platforms is critical.

We have this with Avalon today. If you use the sevak component from avalon, <http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/sevak/>, you can make a servlet Servicable. You can then run your sevak component inside of Phoenix, and voila, you can have cocoon components look up Phoenix blocks!

By going with an "open" container platform ("open" being that the license is compatible and it is just a container / component contract, explicitly designed for reuse), ease of integration with other component systems is that much easier.

While we can do that with our own container, I think it comes down to which is more work:

* Maintaining your own container
* Dealing with an external containers development priorities and community


With avalon, the latter has been more work. I don't think a sour avalon experience should turn us away from looking at containers from other normal communities.

Really, I'm +1 on pushing the platform forward, whichever direction it is. Its the progress that's important :)
-pete




Reply via email to