Stefano Mazzocchi wrote: > > I want to create a migration path away from avalon. > > I propose to have a sandbox so that people know that somehow > they should be thinking about migration. It's sort of a > framework deprecation signal. > > The idea is that we'll start with a sandbox, then people > realize that blocks give them better functionality, so they > make an effort to pay the "migration cost" because of the > additional functionality. > > This will take a while, potentially years, and after that > period, we can remove the sandbox, unlocking ourselves from avalon. > > On the other hand, Carsten, what you are proposing locks us > forever connected to a particular years-old version of avalon > that might be soon deprecated by its own project. > No, no, perhaps my explanations are not good - I don't know.
All I'm still trying to say is, that I would like support for the avalon lifecycle interfaces. So, precisly, I want to have support for: LogEnabled, Contextualizable, Configurable, Parameterizable, Serviceable, Intializable, Startable, Disposable, ThreadSafe and Poolable. Nothing more. I'm not against defining new interfaces - as long as we still support the old ones. And I'm not against in loosing *some* functionality if I'm using those interfaces from above. Most of them are simple to support. The only one might be Serviceable. > Would the need to modify/update avalon framework emerge, we > would be required to change it, this will create a fork. > There is no need to modify/update the avalon framework. We can do our own thing but just support the old interfaces listed above. So, I just want some kind of "legacy support". Carsten
