Just some observations

[Berin Loritsch <bl...@d-haven.org>]

I'll be honest, I haven't gotten through all the email over the past
weekend, so I am behind.  However, there has been some talk about
adjusting the framework, and the lookup mechanisms.  The purpose of
this mail is to reintroduce some of the thought about why things are
the way they are.  Please take it as such.  Remember, if we don't learn
from the past we are doomed to repeat our past mistakes.

In the past we had our share of hyperbole and bike shed arguments.  The
reason being that we were creating a cathedral.  This is a harsh
realization, since most people assume that open source == bazaar.
Nevertheless in a cathedral everything is important, the size, shape,
and material used for door handles is just as important as the altar
inside.  In a cathedral environment, the difference between "init()"
and "initialize()" is very important.  It is a religious experience
of sorts.  That is where Avalon came from, and a good source of debate
about a great number of things.

Moving on to the selection mechanism.  We discussed ad nauseum the pros,
cons, and reasons why we should use a String instead of a more specific
object.  Why a string instead of the generic Object.  We came up with
the ComponentManager and ComponentSelector interfaces, we knew it wasn't
perfect but it fit a couple needs.  One of the things we really tried to
do was to maintain some security in the model.

In a secure environment, there was no provision for searching for the
different components available.  Either the container gave you something
or it didn't.  The Sitemap knew that there was going to be a
specifically configured Generator named "file", either due to
omniscience or the configuration.  The concept was that the Sitemap
shouldn't have the ability to go through all the Generators and find
what was available.  Why?  Because that ability would also enable
maliscious components to do the same thing.  We had the idea, but we
only had implementations of the protection with varying degrees of
success.

Next was the subject of whether we should use the interface's class or
not.  We chose not mainly because of classloading issues.  What happens
if the interface class is not loaded in?  Well, that reasoning was
somewhat shortsighted due to the fact that the component would not be
able to be loaded unless the class existed--unless of course the whole
thing was done through reflection.  Nevertheless, there was the distinct
possibility that the interface might be looked up though one
classloader, and the implementation supplied by another.  Unfortunately
Generator.class loaded from ClassLoaderOne is not the same as
Generator.class loaded from ClassLoaderTwo.  It is this distinct issue
we wanted to avoid.  Now with proxies we can create a bridge between
the classloaders.

Lastly we had very long discussions about whether or not there should
be a lookup(TYPE,NAME) lookup.  One version of Cocoon did have this
named lookup (it was called NamedComponentManager).  However, the
folks who were there at the time were not in favor.  The compromise
was the ComponentSelector--even though I know Peter D would have
preferred to use plain old strings with some parsing semantics.  That
would not be too different from JNDI.  In fact we explored JNDI at
one point as the lookup mechanism.  I championed the cause, and then
Peter and I convinced each other of our cases so well that we flip-
flopped.  Peter finally conceded under protest to allow the selector,
but never supported it in Phoenix using what he felt were better
semantics.

This brings us to where we are today.  In some respects we have come
around full circle on some things.  Personally, I have learned from
history, and attempting to get Axis on board with Avalon, among other
things that people have very good reasons why they don't want to do
something--and they are right for them and their project.

For me, I started Dojo as a way to pursue component oriented programming
without forcing everyone to paint their bikeshed the same color, which
is kind of what Avalon does with the interfaces in Framework.  Instead,
it merely says we are providing the infrastructure for the bikseshed,
and it is up to you how you want to deck it out.  And if you want to
operate with someone else's bikeshed, we'll provide a way for that to
happen as well.

I can see me now as a bald headed child saying, "Don't try to bend the
framework.  The framework is not there.  Instead, bend the air around
the framework".  (Matrix ref for fun).

Most of us were here to witness the removal of the Component interface
and the introduction of the ServiceManager.  And that pretty much brings
us to where we are now.

In order to come up with the next thing, you have to ask yourself some
tough questions: what worked, what got in the way, and what would I
change?  Lastly, if I got my way, would that inadvertantly make
something else not work as well?

Just KISS (Keep It Simple, Stupid).  Don't overthink things--but do
change the titles of messages so that we know when a new topic is
started.

-- 

"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
                 - Rich Cook


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