[METRO] Evolution or revolution
Niclas Hedhman
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
as;
* 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.
Cheers
Niclas
More information about the dev-dpml
mailing list