Nathaniel Alfred wrote:
Instead of a micro kernel which is going to have again a large footprint to do
anything useful I'd rather prefer a small kernel to do just what Cocoon needs.
After all Cocoon is just a super-servlet which needs a bit of container
services for managing component reuse and state information. We should not
make it again the playground for container academics.
While I agree with parts of your post I simply can't agree with "After
all Cocoon is just a super-servlet which needs a bit of container
services for managing component reuse and state information.". While
the current Cocoon may simply be a "super-servlet" (although I see it as
far more than that) with "real-blocks" it will need much more than "a
bit of container services". IMO that is why we have been struggling so
long to get them out - we simply don't have the complete kernel to make
them work. We have modified the core in 2.2 to (mostly) get rid of
Avalon, but the functionality needed for real block deployment doesn't
exist yet. And it certainly isn't trivial to implement.
I agree that Cocoon shouldn't be a "playground for container academics",
but leveraging technologies that do what we need, are proven to work,
and have a stable community supporting them are far from that. Frankly,
I find writing our own stuff to do this more of a playground then
leveraging stuff that already works.
However, I will temper my optimism with the caveat that we do have to be
extremely careful of some of the concerns that have been mentioned; i.e.
accessing the source and jars must not require a full Eclipse download
and strong community support must be there.
Ralph
