[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