avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject On Multiple Containers
Date Wed, 20 Nov 2002 14:03:27 GMT
Multiple containers are not only helpful, but they are absolutely necessary.
We will never be able to converge on the most generic and useable container
specifications when there is only one to choose from.  Using different
approaches that all work with the same components helps us to determine
important criteria such as:

1) Is the component *truly* supported accross containers?  I.e. with the
   same meta data specified the same way, will the component function?

2) Which core feature-set is *critical*?  I.e. not all features for
components
   are necessary in all situations.  Which features can be ignored with the
   component still able to function as expected?  The list of critical and
   _nice_ features help to determine what belongs in Framework.  The current
   Framework is definitely critical.  The "Instrumentable" interface is most
   definitely a nicety, but it does not affect the component's ability to
function.

3) What is the best way to perform a function?  Using the example of our
   pooling code, we had at one point three different pooling mechanisms.
   The best points from all three mechanisms were merged into one unified
   approach.  If it goes in Framework, the interfaces must be correct, and
   any implementations need to be the best.

Having multiple containers is not only workable, but they are critical to
the process of finding out what needs to be in framework and what is
container specific.  It will also help address the issue of how to handle
things such as component extensions in a cross platform way, and how
to make the component still work if extensions are not used.

Considering that Stephen and I (primary developers on the two competing
containers in Excalibur) have proven that we are able to work with each
other, I don't think we will run into any serious or unresolvable problems.
I believe that using metadata is the way to go, but I am not convinced that
either Meta or Info are the best way to express it.  If we can come up with
one specification for how the meta information is *stored*, we can have
multiple implementations like Meta and Info that make reading the metainfo
easier.

I would propose working with the Jakarta Commons Clazz project to help
implement class/method attributes.  That would provide the best way to
ensure a generic solution that is used and maintained by more than just
Avalon.  I think that is the best solution as it raises the synergy with
Jakarta (whom we just left) and with each other.  If a third party is
maintaining that critical piece of code, then there is no chance of
personality conflicts here.  Furthermore, we are not the primary on that
project so that it forces us to be on our best behavior (esp. if we want
commit privs for that project).


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


Mime
View raw message