The following idea came to my mind during the weekend. All the recent discussions about a new core/container etc. show that a possible future version of Cocoon will have a different component handling than we have now.
One major concern for me is compatibility. It would be bad if someone had to rewrite his complete application just to update from one version of Cocoon to another. I guess we all agree on this. Now reaching this goal can be done from two sides: a) The new version can have a compatibility layer. b) We can provide a smooth transition from version to version. It would be ideal if we would have both. But with a compatibility layer people tend to just use it without migrating their app. I wondered what we can do to build a better transition and to get users moving away from our current approach to a newer version. A possible way would be to make minor improvements or modifications from version to version until we reach our goal. This could e.g. be done by building ECM++ for Cocoon 2.2. The basic idea is to build an own version of ECM, which is: grabbing the current ECM code, removing everything we don't need and build a complete container in Cocoon that provides the minimum functionality. This would be: - using the same configuration (roles and xconf) - provide support of the following avalon based interfaces: LogEnabled, Contextualizable, Parameterizable, Configurable, Serviceable, Disposable, Initializable, Startable What could be the benefit of this? - no support for Composable, Component etc. anymore (so no proxies and wired wrapping anymore). - no LogKitManagable, RoleManager support etc. - no Instrumentation support - we could our own instrumentation (JMX?) - All the code for this container would be ours - only the marker interfaces are of course from Avalon. - We could easily add new features, like the selector handling or the DI from Fortress. Using Fortress is imho out of question as it does rely on too many third party code. By having our own container implementation we could add any support that we think that makes sense for providing a smooth migration path - whereever this path ends :) Now, doing this is fairly easy; it requires just a bunch of code and would reduce our depencies while giving us more flexibility. I just started with this approach and could finish it in the next days if people think it is worth going this way. It would give 2.2 more meat as well. But perhaps this idea is totally foolish? Thoughts? Comments? Carsten Carsten Ziegeler Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.net/weblogs/rael/
