Thus the proposal to write and maintain our own, in order to finally, once and for all, build on stone and escape the social quicksands in core depenendies.
Makes perfect sense to me. I guess we should look at our current investment in ECM knowledge & code, look at Pier's alternative, and basically decide and JFDI. We gave Avalon a loyal "customer" to deal with in the past, but there never was a life-time engagement contract. We already missed various new container efforts over @ Avalon, and I'm confident we now know what we need and are able to build it ourselves in the (new) core of Cocoon. Given the flurry of new containers out there, I think people are demonstrating that container development is not rocket science - and since it's core to Cocoon's operations, it's sensible to deal with that ourselves.
There will be aspects of backward-compatibility to deal with, which we can deal with by providing compatibility layers, or by just going for Cocoon 3.0. 2.1 is there, it's solid and used a lot, and if there's consensus that innovation should not be hindered by compatibility, we can simply vote and start 3.0. I would humbly suggest not to change the syntax of the sitemap into Lisp, though. ;-)
Fire at will: I have my abstesto underwear on.
I honestly see no reason why. Thanks for biting the bullet, and even more thanks to step up and agree to do part of the coding effort. I hope many will join you.
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source Java & XML An Orixo Member Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
