> From the last email thread about "Merlin's Future with Avalon", there was an > undue level of defensiveness. The point of the email was not disparage Merlin > or its creator, but to raise awareness about Merlin and see if we can generate > interest in that project. Because of the use of the word "divergent" do > describe the fact that the way Merlin interacts with components does not match > up to some current uses, the Merlin's creator became very defensive. As an outside (non-committer, that is) it seems understandable why the creator might become defensive (right or wrong) about the current efforts in Merlin as being described "divergent" in so far as many efforts are an attempt to create framework layers (keeping interface/implemenation separate) which define the container/component contract via meta information in a container independent manner. If Merlin is indeed an exploration of possibilities, an attempt to evolutionize Avalon, then when sincere attempts to create a unifying layer that all containers can conform to are called "divergent", misunderstanding and defensiveness follow. After all, how can a "unification" effort truly be "divergent". And in what areas has this effort really changed from the norm? Yes you have cited a few areas of concern, but these citings could be construed as an attempt to hamper Merlin development in favor of supporting another container implementation. In fact, only two areas of concern are addressed!
<snip/> > Please do not overreact to statements which you may believe are patently false > or misleading. DO try to find any truth in the statements you can find, it is > usually there. DO ask calm questions to obtain clarification. DO NOT resort > to attacking the character, intelligence, or other personal attributes of the > person who made those comments. Yes! > > The purpose of the afforementioned email was part of a three step plan: > > 1. Determine the level of developer interest (I think we had roughly four > developers other than Merlin's creator that were interested). > > 2. If there is enough interest, identify the areas where Merlin does things > differently for functionality that already exists and is already defined. > Phoenix is our de-facto standard, unless we have come up with a standard > that supercedes it such as AMTAGS. > > 3. Work through the implementation details, and get Merlin released. > > This again is part of a much larger plan: > > 1. Identify what things should be standards, and what things can be made > into container extensions. > > 2. Start writing extensions to handle the extra container functionalities, > which will help evolve the container extension API. > > 3. When all containers are merely a shell, merge them into one shell that > is the best. > > I see the fact that we currently have three containers to be a benefit, as > they each represent a different set of requirements. By the time we are done, > we will be able to have the super container some of us wanted to write from > scratch. > > The only way we can achieve these goals is if we work together. We can only > work together if we stop taking the defensive stance all the time. Can we > agree to swallow our pride and work to the common good of all the people > represented by this project? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
