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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
