hammett wrote: > > Just to make sure: we have the minimum set of interfaces defined (?) Is > 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. Chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
