Thinking framework is not something I'm accustomed to doing - but its been a topic earlier in the week that has been a source of some heated debate. I think I may be getting to the point where I understand why.
The purpose of this post is to present a theory - see if it has any merit.
The Avalon Framework --------------------
For as long as I can remember the Avalon Framework has existed and it
has held a special place within the Avalon community. A great deal of attention has been paid to ensuring framework compatibility, its packages are known buy all developers - logging, configuration, parameters, service, activity and the deprecated component package. We are all familiar with Context, ServiceManager, Configuration, Logger, etc. Most of us can cut lifecycle code with our eyes closed. It is the definitive Avalon.
Abstract Semantics ------------------
Within the Avalon family of technology developments there are a number of containers each using the Avalon Framework - the same classnames for lifecycle artifacts, the same artifact delivery mechanisms, but in specific areas quite different semantics. 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.
When we look at the way different containers deal with these abstract semantics, we see varying levels of meta info usage. It seems to me that as you move more information into meta, you are directly reducing dependence on these abstract semantics while also changing where the valuable information is - instead of being encoded in an application, its in xinfo, xconfig, xprofile files (or whatever you use to hold meta-info in). At the same time the framework becomes less and less central and the thing that is "definitive Avalon" starts looking like nothing more than a delivery vehicle and a few utility classes.
I think it is safe to assert shift in value this creates a completely different "appreciation" of the role of framework as "product" between
different user communities.
Same pattern - different interfaces? ------------------------------------
I'm asking myself if interfaces defining an abstract semantics should not be properly considered as conceptually abstract classes. Imagine for a moment that Context was declared as abstract interface (i.e. requires a concrete specialization before being used in a public interface). I'm going to call this a type-safe semantics.
Following this line of reasoning it seems to me that we will inevitably
end up with different frameworks sharing similar patterns, some common
utilities, and potential common non-abstract interfaces. What that means is that there should be room for and anticipation of a movement away from framework by heavily meta-driven products.
Conclusion ----------
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.
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.
On my first conclusion - I hope that this is a step toward understanding or at lest explaining potential differences in perception. As to the second conclusion - I'm not sure where this line of reasoning is taking me but I do like the notion of type-safe-semantics.
WDYT?
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
