Stephen McConnell wrote:
These areas mainly concern context and service lookup. There are others areas such as configuration management and lifestyle where subtle differences exist. I think can be summarized by saying that the framework presents a number of abstract semantic concepts presented though concrete interfaces and classes.
Are you saying (through a cloud of elaboration) that one could possibly argue that the introduction of
public interface FortressServiceManager extends ServiceManager
{}public interface MerlinServiceManager extends ServiceManager
{}and having
public class MyComponent
implements FortressServiceable, MerlinServiceable
{
public void service( FortressServiceManager man )
{
:
} public void service( MerlinServiceManager man )
{
:
}
}would be a way for the clarification of what the component's expectation of the lookup semantics should be ?
And in that, rather directly define the semantics of each case where there is now so much controversy, and even allowing containers to support more than one set of semantics for this components, as well as allowing components to easier be compatible with more than one container??
If so, I think this sounds like a great idea, and keen to hear what Berin & Co would think of something along these lines.
As concerns right now - I think its safe to say that the meaning of framework to one community is very different to the meaning in another - and is probably the root technical issue underling the recent tension on framework positioning and the associated web content.
You got that right :o) And the question would rise, is a convergence in semantics desirable, or shall we just accept such differences and move forward with dealing with such world ?
Secondly, if the notion of type-safe semantics has merit it would
suggest that the framework as a common shared library maybe convenient,
it may also be an unwitting source of deception that we should at least be aware of.
Source of Deception ?? Pretty strong words, since it is not intentional. But let's agree that at the moment there are semantic holes that are not apparent looking at Framework in isolation.
WDYT?
I think that you are on to something that the different Avalon container authors can start a discussion around, and see if we can find mechanisms that empower the component author, but foremost the component assemblers, to use mixes of components designed for one container and deployed in another. If there is a desire to co-exist, and help each other forward, "Type-safe Semantics" could be a seed to new solutions to our principal technical disputes.
Cheers Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
