Sorry, I mistakenly sent prematurely!
==============================

> 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/>
* All your context entries use the full URN notation, which makes Merlin
   the only container to support this styling.
<snip/>
String and URL object for 'Context.get( )' seems standard -- as illustrated
in Berin's 'Developing with Avalon'. How then is using a String URN really
that divergent?


<snip/>
* Merlin suggests that there is much more in the avalon namespace than
   anyone has agreed to.  AMTAGS is our current standard--it needs to
   be adjusted, but it is what we have.  Merlin does not comply.

<snip/>
Does Merlin not support ANY of the AMTAGS or does it support MORE?  Could
you be more specific on how it does not comply?

<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).
There may have been  4 replys only, which does not necessary reflect
interest.  I for one am quite 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.
What benefit would the community get from having Merlin need to conform to
"functionality that already exists and is already defined", and what
specifically are you referring to other than the aforementioned?

<snip/>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to