Stefano Mazzocchi wrote:


Potentially possible, but I wouldn't do it, we need to be able to keep the 2.1 tree clean.


Berin, how long would you think it would take you to do the migration?

The simple migration will be fairly quick. For instance, it would take a couple of hours. The additional features, however, would take a bit more time. 90% could be worked around initially just by taking advantage of the way current Servlet containers work.

do you have a list of things that worry you most?

With help, I think we can migrate and stablize Cocoon 2.2 rather quickly. Cocoon would still need to extend Fortress a little to get the dynamically compiled generators (XSP) and such. We also might need to create a new LifecycleHandler for Request bound components. The thing is passing the request object to the handler. We could do this with a more dynamic Context object, or we could use the Lifecycle Extensions API, or we could do a bit more like current ECM is operating.

These things will take some time to shake out the details for a better/pure
environment, but Cocoon would be usable after the initial port.  The XSP
might be a disabled for a day or two, though.


BTW, why can't we do the migration *after* we implement the blocks?

We can do it whenever you like. I just need to know when you guys want it. When I have the green light, I will start working on it.


I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container.

:) You know, I have a feeling that the more modern Avalon container will open up the doors to things you may not have thought possible beforehand. I think you will find the new container and blocks will have a symbiotic relationship. Whichever you choose to implement first is up to you.

--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin



Reply via email to