[METRO] Evolution or revolution
niclas at hedhman.org
Tue Mar 22 00:19:18 EST 2005
On Tuesday 22 March 2005 06:17, Peter Neubauer wrote:
> 1) Cleanup of Metro code
> 2) Removal of never finished/ never used features from Avalon/Merlin
> 3) Replace ServiceManager by Inner Interfaces
> 4) Replace Configuration and Parameters by calls to a management view on
> the component
> 5) Pushing of runtime functionality of Metro into compiletime functionality
> - from Metro into Magic (e.g. assembly phase) in order to catch errors
> earlier and to speed up startup time (e.g. jar scanning for types)
> 6) "parts" and hard aggregation/true composition of components
> 7) Support for arbitrary component strategies (like Pico style, Avalon
> style, Metro style etc) and their versioning (see Steves original mail),
> and introducing a model concept that can hold/expose the data needed for
> different strategies simultaneously
> 8) Introducing of a microkernel in Metro
> 9) World dominance.
For those of you who follows the commit messages, you can see that Steve is
already pounding away on 1) and 2).
A stack of not and/or barely used features has already been butchered, such
* Code Security (incorrectly implemented and no value add)
* LifeCycle extensions
* Java Extension API support
* Phoenix block support.
* Feature-based service provider selection.
A general clean-up of dead-code has also been done.
I would like to add that we want to make a Model/View/Controller separation of
the current Composition Model, and I suspect that such refactoring could
possibly reveal new options on how to progress on the evolutionary path.
I will dive in and help Steve out on occassions, and I am confident that the
evolutionary path can bring us very close to Bullet, and perhaps the
revolutionary step will be much smaller than we first thought.
More information about the dev-dpml