avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject thinking framework
Date Sat, 17 Jul 2004 17:31:30 GMT

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

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.


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.



| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |

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

View raw message