Sylvain Wallez wrote: > > You have to consider two very different things: > - the Avalon framework APIs (LogEnabled, Serviceable, > Configurable, etc.) > - the container that implements the framework behaviour > > Although the container implementation may change, there's a > strong commitment to the framework APIs as this is what we've > used and invested in for many years. > > So even if a new container comes with new features (e.g. IOC > type 2/3), it will also have to implement the Avalon > framework behaviour. We cannot trash years of use of this API > overnight. > I don't want to freak out again but if you look at the discussions about the block implementations, there were a lot of discussions to also remove the framework api from the block system. So if you want to use the benefit of blocks, you can't use the avalon framework api for your components. And I still think this is bad.
Anyways, if for example we would move to Fortress (without using the meta-info stuff and keeping our current configuration files which is possible!) we could add own lifecycle interfaces over time and provide a smooth migration path to whatever comes with blocks. Carsten
