Paul:
You said the following which go me thinking: > > I'm not so sure. We're trying to sell Component > > assembly, component orientated programming. With the > > proposal with Service as the replacement word, we've > > duplicated an entire package. For me the "real" debate should be about the content of the framework/component package. I believe that the current content (ComponentManger etc.) should be depreciated based on the proposal for framework/service and that the "component" package should contain the set of "real" component utilities - utilities that really help with the aggregation of component management aspects. Note that I'm using the term "aspect" to focus on a particular behavioural element of a component (e.g. Contextualization/Parameterization is one aspect, Logging is a nother aspect, service provisioning and decommissioning is a third aspect, etc.). For example - a valid "component" package class would be a real component manager - i.e. something that provides the bootstrap logging establishment, provides support for pipelining of components, through respective aspects. I'm thinking about something totally based on framework interfaces and default implementations (i.e. independent of Excalibur and Phoenix). Imagine the sales potential when you are backed by a tool-set that really adds component integrity to the framework. Cheers, Steve. Stephen J. McConnell, OSM sarl digital products for a global economy http://www.osm.net mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
