avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geer, Christopher S" <christopher.s.g...@lmco.com>
Subject Something Missing? (Was: [Avalon.NET] Status)
Date Tue, 12 Aug 2003 15:56:07 GMT
hammett wrote:
> Just to make sure: we have the minimum set of interfaces defined (?)
> there something missing or to be defined?

Well, one of the advantages of being on vacation for a week is you have
a lot of time on your hands to think, on disadvantage is you have a lot
of time on your hands to think. Anyway, that was my situation last week
and this question came up a lot. I'm not sure the framework, in its
current state, has gone far enough (or maybe it has gone too far but
still missed the mark it was trying to hit).

On the side of it hasn't gone far enough I question if we can stop at
just defining component interfaces, and if they do make sense. For
example, should there be a difference between a component and a service?
Isn't a service really a collection of components that perform a
specific task? Also, should there be an application level that is a
collection of related services? In the recent past we were talking about
the interfaces that the framework defines and got a little stuck around
Startable and Initializable for example. I think us all (or mostly)
agree that they are both useful but looking back on it, is a component
really startable or stoppable? I believe that a Service or Application
is but not really a component. Also, if we look at Suspendable, I agree
this really doesn't make sense for a Component but does make sense again
for an application and service. 

This also requires us to think of deployment a little. While I tend to
agree that each container is responsible for defining its deployment
strategy, I also think that there should be some common guidelines that
they should meet. For example, if the framework goes and defines
components, services and applications then the containers have to have
ways to handle all three (albeit, in potentially different matters).
Maybe the framework should include some "Implementation Specs" along
with the interfaces (as suggested by someone earlier). 


If we go down the other path that the framework needs to be scaled back
then maybe lifecycle and "component" definition shouldn't be included at
all. Maybe the framework (not a really good name in this scenario but
bare with it for now) should only contain the nano-kernel that Berin has
been discussing. This nano-kernel would be just enough code to startup,
find the available plug-ins and load them up. The plug-ins would then
take care of things like lifecycle management, security and other
functions so that they are replaceable over time. The framework would
just define a base set of extension points for the core plug-ins while
the plug-ins could then define more. (This idea has really stemmed from
spending too much time reading up on the inner working of Eclipse if you
hadn't noticed yet) This approach would really take us away from the
competing container model because your container would be the collection
of plug-ins that you need to get the job done. Obviously not every
plug-in would work with every other one so there would still need to be
"container projects", but they would be more responsible for having
collected the plug-ins that they recommend.


Anyway, this may be a bit of a radical view (or views really) but this
might be the right time to start thinking about this since we have a
testing arena with Avalon.NET. 


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message