cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Building ECM++ for 2.2
Date Mon, 18 Oct 2004 16:40:37 GMT
Carsten Ziegeler wrote:

> 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?


the reasons to follow up right after in another RT


View raw message