> This is much more a tools question that a organization question - i.e. 
> if the tools are right then its not a problem - and inverly, if the 
> tools are not thee then reorganization is a solution.

I agree it's also a way to work around classloader issues confronted by
a microkernel.

> In general I agree.  However - keep in mind that by reducing inversely 
> you reduce flexibly.  With fine-grain breakout you can easily map 
> different implementations in on-the-fly (without taking down your system).

Right dynamic reloading will eventually be a concern and #4 below is a
valid point.  However we don't know which parts of eve are going to need
this and which are not at this point.  When we get to the stage where
dymnamic loading is even on our radar screen we can follow these
tactics.  For the time being it severly limits us because of the tools
we use or don't have rather.  

So might we fall back into this layout.  Perhaps but I think the wrapper
projects are where this can be localized.  First its a nice place to
keep it because its away from the core eve code.  Secondly some
containers will be able to take advantage of this and provide hot block
swaping and others will not.  So why should we plan for all of them in
the core.  I know the Merlin kernel will evenually support hot block
swapping because of the meticulous detail to the class loading scheme. 
Others may not.  If we do have a per-component breakdown the wrapper
level is the best place for it.  WDYT?

> > What are the goals?
> > 
> > 1). Keep it simple stupid (KISS)!
> 
> +1
> 
> > 2). Minimize the learning curve and setup overhead for new commers 
> >     (KISS Helps)
> 
> +1
> 
> > 3). Allow Eve deployment with any microkernel
> 
> and (4) allow hot-block management .. i.e. natural evolution of your 
> system while maintaining a running system.  But archiving this objective 
> is in direct conflict with 1 and 2 unless your have the right tools.

Alex