avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Merlin's Future with Avalon
Date Fri, 18 Jul 2003 18:14:25 GMT


Berin Loritsch wrote:

> Stephen McConnell wrote:
>
>> Berin:
>>
>> I read though your reply a couple of time and totally failed to 
>> locate anything that supported you claim that Merlin is divergent.  
>> About the only concrete statement was the following - and that left 
>> me somewhat confused ...
>
>
> You get very defensive everytime I mention Merlin in light of Phoenix
> and Fortress.  What's the deal?  


I think your assertions on thread have been missleading. 

> Last time I checked we were on the same
> team. 


We are on the same team Berin.

>
>
>>
>>>
>>> Fortress and Phoenix share a subset of meta-info descriptors
>>
>>
>>
>>
>>
>> What is the subset of meta-info that Fortress and Phoenix share?  It 
>> is my impression that Fortress and Phoenix have take divergent paths 
>> (I'm inspired by your own creative application of this word).  
>> Fortress keys of a @avalon.component whereas Phoenix keys of 
>> @phoenix.component for one variant of its meta-model and 
>> @phoenix.block for what it calls legacy support for the <blockinfo> 
>> style (neither of which have anything to do with Fortress or 
>> Merlin).  If we dig into the actual descriptors the differences 
>> between Fortress and Phoenix are even more distinct and container 
>> specific relative to anything in Merlin.  Given that the meta-info 
>> package we are separating out from Merlin includes fully support for 
>> the legacy Phoenix model, along with support for the declaration of 
>> Fortress context assumptions, and provides complete support for the 
>> Avalon context spec. - it would be really helpful if you could 
>> clarify for me what it is that prompts you to suggest that Merlin is 
>> divergent?
>
>
> First:
>
> Do not make statements that cast doubt on the intelligence of your peers. 


I'm not casting doubt on your intelligence - I'm actually complementing 
you on your creativity.

>
> This does not help your position, but rather hurts it.  (I am 
> referring to
> your parenthetical statement in the second sentence of the above 
> paragraph).
>
> Second:
>
> AMTAGS is in use with both Fortress and Phoenix.  Because Phoenix was our
> first forray into the world of meta-info and context entries, it is our
> de facto standard.


Please take a closer look at what I said above and the prior discussions 
concerning AMTAGS. I also suggest you take a closer look at Phoenix, tag 
usage and meta-model before presenting the Phoenix/Fortress commonality 
as a case supporting your position.  Also, it would be perhaps wise if 
we stay away from assertions such as "first" == "de facto standard".  
Standards are built either through consensus or convergence based on 
needs.  Consensus is a result of collaboration whereas convergence is 
more typically a result of adoption in order to gain some tangible 
benefit.   In the case of AMTAGS it is neither - it is simply a starting 
point in the process of potentially establishing a standard.


> If the standard needs to be changed, we need to identify
> what and how.
>
> As to how Merlin is divergent (hopefully you will get it this time):
>
> * All your context entries use the full URN notation, which makes Merlin
>   the only container to support this styling. 


How is this divergent?  It actually reflects discussions on this list.  
It addresses on of the interoperability stumbling points that constantly 
reappears - namely assumptions by containers about context.  The usage 
of URN style naming in no way inhibits the application of Merlin nor 
forces any constraint on component authors.  I simply do not see how 
this is any shape of form supports you divergence theory. 

>
> * 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.


This has already been addressed under another thread.  Merlin does not 
comply for some very good reason.  The AMTAGS proposal as it stands 
today is woefully insufficient - clearly insufficient to meet Merlin 
needs - and keep in mind that Merlin "needs" translate directly to 
component management without container lock-in.  Beyond that, you are 
aware of the actions I've been taking to address AMTAGS and arrive at 
something workable.  If this is the source of divergence that your so 
keen on pressing home - then I suggest to that there are perhaps better 
and more constructive approaches to raising this. 

>
>>
>> Can I should assume that your statement concerning "divergence" was 
>> perhaps just a touch off the mark?  Perhaps you meant to say "open", 
>> "adaptive",  "encompassing", or dare I say "all-embarrassing"?
>
>
> Steve, this last comment is unnecessary.  Please refrain from such 
> comments
> as they do not help. 


Berin - this entire thread is unnecessary!

;-)

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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


Mime
View raw message