[Chair Hat Off] Moving On (was Re: [Chair Hat] Defensiveness is Unnecessary)

[Berin Loritsch <bl...@apache.org>]

Daniel Krieg wrote:

> 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!

I take your points under consideration, but please be open to the bigger
picture.  When the Avalon name is stamped on something, it means that there
is both consensus and support for that thing.  Stephen's work is admirable,
but to date does not represent the full council of Avalon developers.  That
does not mean that his work was useless, or that the current level of other
containers should not change.

In fact here is a list of things I sincerely believe:

1) Our container/component contracts need to unified.
    a) That unification should scoped by namespace.
    b) The Avalon namespace should be reserved for things
       that we ALL agree on.
    c) Other namespaces can be used for new and other
       exciting ways of extending the container.  Those
       namespaces should be organized by function/feature.
    d) This arrangement will allow things to be modular and new developments
       to take place without affecting current component writers.

2) Evolution needs to continue.  We don't have it perfect, but we have something
    good.  We need to build on that, and deprecate certain things that need
    to be deprecated.

3) We don't all have the big picture of all the requirements and what points
    it makes sense to unify on.  The only way to do that is build upon community
    discussion.

Beyond this, there is a difference between expressing displeasure in how
something was stated, and growing hostile without finding the original author's
intent.  That is what happened in this case.  More energy was focused on the
word "divergent" which was actually the one way that I thought it would be best
received (in hindsight it wasn't) than on the issue that I raised.

This is not a personality contest, or a popularity contest, or a product bashing
contest.  This is about raising developer awareness so that we can decide how to
move forward.  To address your other points more directly:


 > <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?

URN has some specific semantics:

urn:avalon:xyz-entry

This states that the key is

1) a URN
2) in the Avalon namespace
3) a standard entry named "xyz-entry"

A Universal Resource Name has the semantics that the name represents a standard
resource that can always be found by that name.

We have not come to community consensus on what context entries belong to the
Avalon namespace, or if URN is going to be the way that we do things.  More
importantly, this "standard" was developed independently of the rest of the
Avalon developer community because in the past Stephen was working in isolation.
He no longer has that luxury, as none of us do.  Anything in an Avalon namespace
must be agreed to by the greater community.  If things cannot be placed in the
Avalon namespace, then it is best to find a functional group namespace where
that entry makes sense.

 > <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?

It does not support the @avalon.component tag, and the @avalon.meta.* tags
were not compliant.  He recently changed the ".meta." portion of the tags
which was a good thing.  The @avalon.service and @avalon.type tags are not
done in a standard manner either.  I believe we need to update the AMTAGS
proposal, so the real change to Merlin should hopefully be small.  The
important thing is that we agree on how to do it.

 >>    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?

Please reread the above sentence.  Please notice the caveat.  ...UNLESS we have
come up with a standard that supercedes it....

It is my expectation that we need to come up with a standard that supercedes
the way Phoenix does some things.  But we need to get there together.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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