RE: Huh? (was Re: Merlin's Future with Avalon)

[Niclas Hedhman]

Paolo wrote:
> The most
> negative jumps of these threads seem to be related to the way any remark
> is taken more than to the way they are made - that is why aggression
> tends to escalate mostly on the reactions.

I partly disagree with your statement. Form of delivery of criticism is
important.

> People just tend to be over-defensive about their baby-project or
> baby-ideas. And then they tend to take any remark as personal and don't
> notice that it is just a debate of ideas.

He/she who has not "killed his butterflies" before, will always tender for
their pet project in over-protective ways. The ability to throw away
something you have worked hard on is not common, but IMHO very valued.

> IMHO it is more positive to focus on developing thicker skins than on
> transforming the Apache mailing lists on the stage of heavy diplomatic
> exercises.

100% agree here.
But looking at Stephen's replies, one could argue that he has thick skin,
just deliver his facts/arguments in a machine gun manner, which is then
not perceived well at the other end. Noone is wrong, still it gets a bit
heated.

I like the Cocoon list. Heated debate, sometimes harsh tones and
borderline of personal attacks, and then "Sorry if you took it that way. I
didn't mean to upset you." remarkably well smooths things over. The
community there is much stronger and thriving in "technical issues"
differencess.

Berin always tries to separate the "technical issues" from "technical
skill" from "community skills", yet it doesn't go down that well in
Avalon-space. Why is that?

Could it be that not enough developers are involved in each piece, not
enough people work across the container borders that exists today?? I
think so. The code is not bad enough, as Stefano would say, it doesn't
itch enough people outside the initial developer(s).



Cheers
Niclas




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

RE: Huh? (was Re: Merlin's Future with Avalon)

[Paulo Gaspar]

Hi Ken and all,


Actually, I think Ken's remarks apply to BOTH Stephen and Berin... and 
most other people participating on Apache lists. =:o)

However, I am not sure that this kind of negative cycle starts because
of the way one makes remarks about someone else's project. The most
negative jumps of these threads seem to be related to the way any remark
is taken more than to the way they are made - that is why aggression
tends to escalate mostly on the reactions.

People just tend to be over-defensive about their baby-project or 
baby-ideas. And then they tend to take any remark as personal and don't
notice that it is just a debate of ideas.

IMHO it is more positive to focus on developing thicker skins than on
transforming the Apache mailing lists on the stage of heavy diplomatic
exercises.

BTW, this is what I like about Sam Ruby: thick skin, very calm
reactions, very economic on words (I have to learn a lot on this one).


I participate less on these lists these days, but I still follow them
regularly. From my perspective it is quite clear that Stephen and Berin
are on the same boat and have the same targets, (as it happens with the
other Avaloners, of course).

If only they could believe (or just remembered) this "same boat" thing...



Just one more thought about agreeing on standards:

Of course that we are all after the Holy Grail of the perfect framework
(hey, this is Avalon!) and of course that we tend to believe that there
is only one Grail...

...BUT none of us is completely sure about how that Holy Grail looks
like and we all often admit that we are still searching.

So, lets not try to find an agreement about how things should look like
when it can be too early. Lets keep giving some room to experimentation
and to try different competing ideas.


Thank you Berin, Stephen and all the others for the work you have been
doing here. I keep learning a lot from you all.


Have fun,
Paulo Gaspar


> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Nicola Ken Barozzi
> Sent: segunda-feira, 21 de Julho de 2003 7:42
> To: [EMAIL PROTECTED]
> Subject: Re: Huh? (was Re: Merlin's Future with Avalon)
> 
> 
> ...
> 
> It does not show. What I think is that your rational intention is not to 
> attack anyone, but emotionally you feel Merlin attacked, and you reply 
> in tone, even if it's not what you want to convey.
> 
> Mail, as well as conversations, is *not* aseptic. Emotions percolate 
> through, if you want it or not.
> 
> ...
> 
> See, you are trying to demonstrate by words and rational arguments that 
> you are right... which is not the thing to do. Think about the 
> "emotional" part: you felt attacked, it showed in your mails, Berin felt 
> it and feels attacked. Now the problem is *not* who is right, but how to 
> make the other *feel* better and not attacked.
> 
> Rational arguments don't work for this, they only make things harder. A 
> simple "sorry if you felt like this, I did not mean to, what can we do 
> to fix the issue" is much more effective.
> 
> Remember that others feel how they feel, not how you would like them to 
> feel.
> 
> ...
>
> Don't do the same errors that you have seen others do and that you have 
> learned to dislike. Please.
> 
> -- 
> Nicola Ken Barozzi   [EMAIL PROTECTED]
>  - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> -
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

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

Re: Huh? (was Re: Merlin's Future with Avalon)

[Nicola Ken Barozzi]

Stephen McConnell wrote, On 19/07/2003 0.03:
...
Berin:

I seems that you want turn anything I say into a personal attack. 
Not only with Berin, Stephen.

...
I'm not attacking you.  
It does not show. What I think is that your rational intention is not to 
attack anyone, but emotionally you feel Merlin attacked, and you reply 
in tone, even if it's not what you want to convey.

Mail, as well as conversations, is *not* aseptic. Emotions percolate 
through, if you want it or not.

...
Let me detail this for you.
See, you are trying to demonstrate by words and rational arguments that 
you are right... which is not the thing to do. Think about the 
"emotional" part: you felt attacked, it showed in your mails, Berin felt 
it and feels attacked. Now the problem is *not* who is right, but how to 
make the other *feel* better and not attacked.

Rational arguments don't work for this, they only make things harder. A 
simple "sorry if you felt like this, I did not mean to, what can we do 
to fix the issue" is much more effective.

Remember that others feel how they feel, not how you would like them to 
feel.

Finally - I would appreciate it if you could drop the "steve's being 
defensive" thing. This is not being defense - it is correcting a mistake 
you have - presumably arising from inaccurate or incomplete assumptions 
you have about the Merlin platform.  If you wish to avoid similar 
patterns in the future - you may want to try to avoid the use of 
negative generalizations.
Read this sentence, then reread it, then reread it. Then again take a 
walk, come back, and read it one last time.

You will hopefully understand that your mails *do* show you as 
defensive, and this is seen by most of your peers IIUC. And if a peer 
has to be careful of how he talks to you, there is a problem.

We have faith in you. You are here and we are working so that Merlin can 
drive the new Avalon container. Facts are positive. Then please stop 
hanging on a single word because it's useless and friction making.

Don't do the same errors that you have seen others do and that you have 
learned to dislike. Please.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

Re: Merlin's Future with Avalon

[david . gray]

Reply in line.




Stephen McConnell <[EMAIL PROTECTED]> on 18/07/2003 17:42:53

Please respond to "Avalon Developers List" <[EMAIL PROTECTED]>

To:Avalon Developers List <[EMAIL PROTECTED]>
cc:

Subject:    Re: Merlin's Future with Avalon



Nicola Ken Barozzi wrote:

>
> B**t, Stephen. You are just generating negative energy, sit down a
> minute and think of it. It's *not* about how to remove "divergent"
> things, it's about how to *integrate* them.


Look, I agree with your 100% All of the "divergency" rubbish it's just
plain b**t. The real important thing here is thinking, ideas and
effort that is going into the issues the deal with a standard Avalon
containment platform.

> Berin said:
> "Before I can be OK with that, we need to ensure that all user
> components are defined consistently across all containers.  The meta
> API separated out is a step in that direction.  We need to be assured
> that the same component used in Merlin will continue to function in
> Fortress, and vice versa. "
>

An observation from a list lurker - I think you all agree that
standardization
is a good goal so now perhaps the various parties should accept this and
start developing the standard for the Avalon containers.

Perhaps if you can all step back and agree on that, progress can be made.
May take
a little bit of give and take but both the developers and the users of the
various containers will benefit.

(Not taking any sides)








NOTICE - This message is intended only for the use of the 
addressee named above and may contain privileged and 
confidential information.  If you are not the intended recipient
of this message you are hereby notified that you must not 
disseminate, copy or take any action based upon it.  If you 
received this message in error please notify HIC immediately.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of HIC.



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

Re: Huh? (was Re: Merlin's Future with Avalon)

[Stephen McConnell]

Berin Loritsch wrote:

Stephen McConnell wrote:


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.


That statement seems to insinuate that I am intentionally being 
misleading.
I am not, furthermore, I do not see where I am being misleading.  
Disagreement
does not equal misleading. 


Berin:

I seems that you want turn anything I say into a personal attack. I'm 
not attacking you.  I said that your assertions on the matter of 
divergence were misleading. I said this because you were conveying 
information which in my opinion was and remains just plain incorrect.  
In doing so I happen to think your misrepresenting the current status of 
things related to Merlin development.  You have said above that you do 
not see where you are being misleading.

Let me detail this for you.

You made a statement suggesting that Merlin was divergent from Phoenix 
and Fortress with respect to component definition. You did not provide 
any details and the time, but after being pressed on the subject, you 
raised two points concerning (a) the application of URNs within Merlin 
and (b) non-conformance with AMTAGS.  I responded - pointing out to you 
that the claims you were making could not reasonably be framed as 
diverse together with the reason why.  I will not repeat everything from 
that message - but instead - I will try to explain to you why your 
conclusions are misleading.

Firstly the subject of the usage of URN patterns within Merlin.  You 
assert that because the Merlin implementation does not follow letter for 
letter existing practices - that it is divergent.  This is grossly 
misleading because in-fact Merlin is neutral with respect to management 
of names.  If you go over the tutorials on Merlin or take a look at the 
sources, you will see that Merlin places *no* restriction on a component 
author. Instead, the implementation enables arbitrary approaches.  What 
is perhaps amusing in all of this is that the Merlin implementation is 
in fact the least diverse with respect to component/container contract 
and component implementation of any Avalon container.  Your comments are 
misrepresenting this reality and creating a false and negative impression.

Your second point attempted to correlate that fact that because the 
Merlin implementation was not embracing an insufficient AMTAGS proposal, 
that Merlin was therefore diverse.  This is misleading - the truth of 
the matter is the AMTAGS proposal as it stands insufficient, as you are 
well aware.  This is not a question of being diverse - it is a question 
of insufficiency of a specification to meet operation requirements.

Finally - I would appreciate it if you could drop the "steve's being 
defensive" thing. This is not being defense - it is correcting a mistake 
you have - presumably arising from inaccurate or incomplete assumptions 
you have about the Merlin platform.  If you wish to avoid similar 
patterns in the future - you may want to try to avoid the use of 
negative generalizations.

Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


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

Huh? (was Re: Merlin's Future with Avalon)

[Berin Loritsch]

Stephen McConnell wrote:


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.
That statement seems to insinuate that I am intentionally being misleading.
I am not, furthermore, I do not see where I am being misleading.  Disagreement
does not equal misleading.
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.
That's like saying "Your pretty smart, for an inbreed."  Keep your backhanded
compliments to yourself please.  They are not appreciated.
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.
That will be the subject of another thread.  However DO realize that Phoenix
is a released container, and as such has more credibility as to how components
are defined and used than Merlin at this stage.  Therefore, it would be wise
to retain as much of that usage as possible so as not to force our users to
rewrite their components or change source code every time we release something.
I get the impression that you fail to realize this.
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.
Those discussions were never adopted as the official way we were going to
do things.  In fact, where it was last left, there was still some disagreement
as to whether we should use URNs or not.  I see that as divergent from
community consensus.
* 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.
I haven't seen anything concrete to support your position, and this subject
deserves its own thread.  I would encourage you to start a thread and detail
exactly what is insufficient in the AMTAGS proposal.

Steve, this last comment is unnecessary.  Please refrain from such 
comments
as they do not help. 
Berin - this entire thread is unnecessary!

;-)
Apparently it is, as you seem not to be learning anything.  Your smiley does
not counteract the slap in the face that your last comment is.  Please learn
how to express your oppinions without attacking the person you disagree with.
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Merlin's Future with Avalon

[Stephen McConnell]

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  
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:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


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

RE: Merlin's Future with Avalon

[Farr, Aaron]

> -Original Message-
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 18, 2003 8:21 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Merlin's Future with Avalon
> 
> 
> Stephen McConnell wrote, On 18/07/2003 12.27:
> 
> >
> > Nicola Ken Barozzi wrote:
> >
> >> I agree with 1, 2.
> >
> > Not with (3) ?
> 
> Sorry, I meant 1 and 3. I'm mildly against the side-by-side container
> approach.

Where (3) was:

> 3 Merlin needs milestone releases to get more feedback

I agree with this.

Even if we don't do actual binary milestone/beta releases, could we at least
regularly tag CVS and publish the tags?  It would avoid some of the issues
we had recently in the "re: getting started with merlin" thread and allow
users to grab a version of merlin that they know will build properly while
still allowing Stephen and other developers to play with the code base.

Just a thought.

jaaron

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

Re: Merlin's Future with Avalon

[Nicola Ken Barozzi]

Stephen McConnell wrote, On 18/07/2003 12.27:

Nicola Ken Barozzi wrote:

I agree with 1, 2. 
Not with (3) ?
Sorry, I meant 1 and 3. I'm mildly against the side-by-side container 
approach.

I'd add another point: to become (1) Merlin must adopt common standard 
contacts, which it currently does not always do, as Berin *correctly* 
pointed out (hence the "divergent" bad work that got you more 
concerned than IMHO was in the original intentions).
Let's not repeat the same bad habits. If there is something "divergent" 
then say what it is. I think it is time to drop this rather feeble line 
of insinuation. If there is something you (or Berin) want to address 
then get to the point and say it - because neither of you have managed 
to articulate anything concrete. If its just there to create a negative 
context then ask yourself the question - why do you think it is 
necessary to do that? I'm confident both you and Berin will get past the 
point of having to having to cast dispersions - but maybe is a chair 
thing and beyond your respective control ;-).
This is a personal attack.

We'll continue discussion when you have calmed down.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

Re: Merlin's Future with Avalon

[Berin Loritsch]

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?  Last time I checked we were on the same
team.

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

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Merlin's Future with Avalon

[Stephen McConnell]

Nicola Ken Barozzi wrote:

Stephen McConnell wrote, On 18/07/2003 9.42:

...

Bottom line is that I don't think we should try to have Merlin 
deprecating Fortress - instead I think we have Fortress deprecating 
things progressively relative to a standard containment architecture. 
The difference is that Fortress would continue to exist to handle the 
delta between what is established as standard, and what is specific 
to the ECM legacy.
...

Basically I envisage a future in which the internals of Merlin are 
changing, evolving and adapting as we move towards the "perfect" 
solution. I should point out that I think that *release* should not 
be interprited as an *we-have-to-maintain-Merlin-API-as-is*. Instead 
- the questions of what *release* actually means should discussed in 
a lot more detail (and on the dev list - not here). In particular, we 
need a release plan that outlines what aspects are volotile, what 
aspects are not. 


Ok, let me try and rephrase in a more succing way what you are saying: 
;-P

1 Merlin/the evolution of it, will be the next Avalon container 


Maybe, maybe not - if this process foldes out how I would like to see it 
fold out - the subject of which container becomes totally academic 
because everthing is hitting the same back-end API.

2 Fortress will not go away because it will deal with legacy components 


Yep.

3 Merlin needs milestone releases to get more feedback 


There are other people here who want to get involved in its 
development/evolution. Getting releases out (similar to the Maven 
approach) provides binary drop-points, which in turn provide greater 
flexibity for people to jump in and do stuff inside Merlin (JMX, JNDI, 
Service Selection, distribution, etc.) against the CVS and greater 
opportunity for people to lock in against binary relases - from this 
comes more feedback and participation.



I agree with 1, 2. 


Not with (3) ?

I'd add another point: to become (1) Merlin must adopt common standard 
contacts, which it currently does not always do, as Berin *correctly* 
pointed out (hence the "divergent" bad work that got you more 
concerned than IMHO was in the original intentions).


Let's not repeat the same bad habits. If there is something "divergent" 
then say what it is. I think it is time to drop this rather feeble line 
of insinuation. If there is something you (or Berin) want to address 
then get to the point and say it - because neither of you have managed 
to articulate anything concrete. If its just there to create a negative 
context then ask yourself the question - why do you think it is 
necessary to do that? I'm confident both you and Berin will get past the 
point of having to having to cast dispersions - but maybe is a chair 
thing and beyond your respective control ;-).

As to you question concerning "what does Fortress provide as legacy that 
Merlin will not provide and why". There are lots of options and I'm not 
about to forecast which is best. Fortress is light-weight - lighter than 
Merlin. There are open questions about how much Fortress should include 
from a common containment platform - the choice between lightweight as 
opposed to feature-rich. But this kind of question is academic. If we do 
things well with respect to containment API, much of this should be 
configurable (including things like selection of the semantic 
assumptions). Think of it like this - you run up your container in 
accordance with a configuration that suites the deployment context you 
want to establish. And when someone asks you which container your using 
- you just look at them with a expression that suggests you don't 
understand – you think about for a moment - then you twig - and you 
answer - Avalon.

Cheers, Steve.



--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


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

Re: Merlin's Future with Avalon

[Nicola Ken Barozzi]

Stephen McConnell wrote, On 18/07/2003 9.42:

...
Bottom line is that I don't think we should try to have Merlin 
deprecating Fortress - instead I think we have Fortress deprecating 
things progressively relative to a standard containment architecture. 
The difference is that Fortress would continue to exist to handle the 
delta between what is established as standard, and what is specific to 
the ECM legacy.
...
Basically I envisage a future in which the internals of Merlin are 
changing, evolving and adapting as we move towards the "perfect" 
solution. I should point out that I think that *release* should not be 
interprited as an *we-have-to-maintain-Merlin-API-as-is*.  Instead - the 
questions of what *release* actually means should discussed in a lot 
more detail (and on the dev list - not here).  In particular, we need a 
release plan that outlines what aspects are volotile, what aspects are 
not. 
Ok, let me try and rephrase in a more succing way what you are saying: ;-P

1 Merlin/the evolution of it, will be the next Avalon container
2 Fortress will not go away because it will deal with legacy components
3 Merlin needs milestone releases to get more feedback
I agree with 1, 2.

I'd add another point: to become (1) Merlin must adopt common standard 
contacts, which it currently does not always do, as Berin *correctly* 
pointed out (hence the "divergent" bad work that got you more concerned 
than IMHO was in the original intentions).

Then we should discuss a bit point 2 (esp you and Berin)

a - What does Fortress provide as legacy that Merlin will not provide 
and why?

b - What about the *implementation* merits of Fortress that Merlin 
lacks? Those would have to be ported as well.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

Re: Merlin's Future with Avalon

[Stephen McConnell]

Nicola Ken Barozzi wrote:

Stephen McConnell wrote, On 17/07/2003 3.37:

...

We cannot have Melin be divergent.  We need one spec to drive the user
expectations. 


One must be careful in how one positions something as divergent.

Which of the following existing and divergent characteristics within 
Merlin would you like to eliminate?


Bullshit, Stephen. You are just generating negative energy, sit down a 
minute and think of it. It's *not* about how to remove "divergent" 
things, it's about how to *integrate* them. 


Look, I agree with your 100% All of the "divergency" rubbish it's just 
plain bullshit. The real important thing here is thinking, ideas and 
effort that is going into the issues the deal with a standard Avalon 
containment platform.

Berin said:
"Before I can be OK with that, we need to ensure that all user 
components are defined consistently across all containers.  The meta 
API separated out is a step in that direction.  We need to be assured 
that the same component used in Merlin will continue to function in 
Fortress, and vice versa. "

To make the same component run in two different containers, you have 
three options:

1 - make the featureful one degrade - which is out of question
2 - make components require a specific container - you know
it's not best
3 - make the other container upgrade to the new features, or even
better make the two integrate into one that has the best of both
Merlin has cool features? Cool! When will it become *the* Avalon 
container? What is missing for it to become so? What does Fortress 
have that cannot and/or will not put into Merlin? 


There are a bunch of things that need to be addressed as part of the 
overall Avalon containment architecture.  I raised most of these on the 
PMC thread concerning Fortress deprication.  I'll repeat those points 
here so that everyone has a picture of the 
issues/scope/whatever-you-want-to-call-it.

[from PMC thread on the same subject]

Fortress uses a different meta-info format and a different meta-data 
model to Merlin.  Meta-info management can be handled via Fortress 
specific tools that generate standard meta-info from Fortress specific 
data (e.g. roles files, @x-avalon stuff, etc.). The same could be done 
at the meta-data layer, however, I don't think we are ready for that 
just yet.  I am currently working on the seperation of meta-data 
management from assembly semantics - when that's complete then we have a 
realistic framework for establishing a common meta-data model.  This 
would enable the potential deprication of container-specific meta-data 
in Merlin, Fortress and Phoenix. The differences are then norrowed down 
to assembly and deployment semantics. Here things get a little fuzzy - 
Fortress tools include assembly logic at build time (by checking 
published services against dependencies) related to a single deployment 
unit (jar file) whereas Merlin assembly validation takes into account 
multiple deployment units.  I.e. there are some open questions here.  As 
far as deployment is concerned, there is the long standing question of 
the semantics related to service lookup and the use of selectors. The 
ROLE/Selector approach used in ECM/Fortress breaks the pridictive 
assembly semantics used in Merlin (in Merlin you have to declare a 
depedency on a selector if you want a selector).  There are other 
issues, but I think I've covered the main points here.

Bottom line is that I don't think we should try to have Merlin 
deprecating Fortress - instead I think we have Fortress deprecating 
things progressively relative to a standard containment architecture. 
The difference is that Fortress would continue to exist to handle the 
delta between what is established as standard, and what is specific to 
the ECM legacy.

Basically I envisage a future in which the internals of Merlin are 
changing, evolving and adapting as we move towards the "perfect" 
solution. I should point out that I think that *release* should not be 
interprited as an *we-have-to-maintain-Merlin-API-as-is*.  Instead - the 
questions of what *release* actually means should discussed in a lot 
more detail (and on the dev list - not here).  In particular, we need a 
release plan that outlines what aspects are volotile, what aspects are 
not.  As an example, the assembly package APIs are thing that I think 
can be improved (if fact I know they can be improved) and I would not 
suggest coding against them at this time - however, writting deployment 
descriptors is another story - XML deployment descriptors need to be 
stable because these are the main interaction point (and everything 
to-date suggests that this is readily achievable and maintainable).

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PR

Re: Merlin's Future with Avalon

[Stephen McConnell]

Berin Loritsch wrote:

Farr, Aaron wrote:


-Original Message-
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
To that end, we need to focus on the AMTAGS proposal and the Context
clarifications.  Currently, there is a similarity in some of the 
component
definitions between Phoenix and Fortress, with Merlin being 
divergent in
these areas.


Perhaps to avoid any misunderstanding, how exactly is Merlin divergent?
The meta-info and meta-data descriptors are different for all three
containers.  This includes assembly, lifestyle identification, and
configuration.  Deployment structure (jar vs sar) is different 
between all
three containers.  Support for lifecycle extensions, nested containers,
context extensions and values are different in all containers.

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

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

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

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


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

Re: Merlin's Future with Avalon

[Berin Loritsch]

Farr, Aaron wrote:


-Original Message-
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
To that end, we need to focus on the AMTAGS proposal and the Context
clarifications.  Currently, there is a similarity in some of the component
definitions between Phoenix and Fortress, with Merlin being divergent in
these areas.


Perhaps to avoid any misunderstanding, how exactly is Merlin divergent? 

The meta-info and meta-data descriptors are different for all three
containers.  This includes assembly, lifestyle identification, and
configuration.  Deployment structure (jar vs sar) is different between all
three containers.  Support for lifecycle extensions, nested containers,
context extensions and values are different in all containers.
Fortress and Phoenix share a subset of meta-info descriptors, as
well as some common context entries.
For now, our concerns rely mostly with

1) Meta information (includes info/data)
2) Context entries
3) Anything that is in the "avalon" namespace.
The assembly is something that needs to be addressed, but I would be
comfortable with addressing it at a later time.  Fortress and Merlin
do share some semantics with configuration--I would like to see that
much be the same between all containers.  Fortress and Merlin do
support lifecycle extensions, though they are declared differently.
It is not a call to trash Merlin and vindicate others.  It is a call
to unify the Avalon namespace.  Anything that is beyond the scope of
the Avalon namespace needs a different namespace.  Component writers
need to know what they can expect in all containers.  If they use
lifecycle extensions, how do they declare them (in AMTAGS, not in
XML which is an implementation concern)?
We already have a certain number of issues on the table, and releasing
Merlin will exacerbate those issues if we have not addressed them
before the release.
My _goal_ is to have a core set of functionality that component writers
can work with, and allow that core functionality to be extended in
ways that make new containers (or more specifically container extensions)
the way of the future.
I wanted to raise the issues for a number of reasons.  The chief of which
is that no sandboxed development can emerge out of the sandbox until there
is proper developer support for it.  If it will have the Apache Avalon
name stamped on it, the Apache Avalon team must be behind it.  I have no
doubt that Stephen has done a wonderful job with Merlin.  It has been
flying under the radar for a long time, and we need to address it sooner
than later.  Esp. if Stephen is hinting about a near release.  It can't
be released without developer backing.  I would prefer to get developer
backing than tell him that Merlin cannot be released.
However the implications of a Merlin release means that we the Avalon
developer community have to get our act together on certain issues.
We do not have to come to a unified featureset, but we do have to come
to a unified set of rules for how to extend the core featureset in
predictable ways.
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Merlin's Future with Avalon

[Stephen McConnell]

Leo Sutic wrote:

 

From: Stephen McConnell [mailto:[EMAIL PROTECTED] 

One must be careful in how one positions something as divergent.

Which of the following existing and divergent characteristics within 
Merlin would you like to eliminate?
   

None, and that's never been the issue.

The issue is this: Will Merlin keep being divergent in those
characteristics or will there be any incorporation of the 
charcteristics into the core Avalon code?
 

Every effort has been made to ensure a good separation of the different 
facilities within Merlin with the objective of enabling identification, 
assessment and potential migration of common container-side facilities. 
There is already a process in place facilitating the migration of the 
meta-info model out of Merlin and into the core Avalon code.  There are 
other facilities that will progressively establish themselves as 
candidates.  Of particular relevance is a common meta data 
representation and a common composition model.

In short, are you willing to codify those characteristics as a standard
that may not fulfill all your wants but will fulfill all your needs, and then
stick to that standard?
Where it makes sense. Take two examples - (a) context, (b) AMTAGS.  
There was a bunch of work we did (headed up by you) on cleaning up the 
definition of the Avalon context contract covering context casting and 
context entry semantics.  These semantics are 100% supported within the 
Merlin platform (context casting, context entry handling, entry alias 
management, etc.).  This is an example of a spec that made sense.  The 
AMTAGS spec. (as it stands today) is an example of a spec that does not 
make sense because it is simply insufficient.  As a consequence AMTAGS 
are not supported in Merlin (although now with work on a common 
meta-info layer, chances are that AMTAGS will be revised to something 
more substantive in which case we may see 100% support in the near future).

One should consider Merlin a work in progress that aims to identify, 
validate, and establish common facility candidates, and, progressively 
incorporate standard facilities.  Over time I am confident that Merlin 
will (a) lead the process of delivering standard Avalon containment, 
while (b) maintaining a healthy and vibrant context for exploration, 
resolution and delivery of advanced distributed service management.

Part of the process of achieving this objective involves the 
establishment of a release process - periodic milestone releases of the 
Merlin platform reflecting its evolution and progressive incorporation 
of a standard Avalon infrastructure.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


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

Re: Merlin's Future with Avalon

[Berin Loritsch]

Stephen McConnell wrote:



Berin:

If I take your "before I can be OK with that" statement literally, I 
should point out to you that there are things in Merlin that are just 
not possible in other containers.  These features (some of which have 
been recently exposed by Vinay in his post concerning custom service 
attributes) are beyond classic Avalon - they go into the area of 
distributed service management.  I am personally really interested in 
this area and I see lots of adventures in this realm - realized and 
delivered through the Merlin platform - as not necessarily compliant nor 
consistent with existing Avalon containers - in fact these very features 
are pushing beyond the "accepted" envelope.

Is that a good thing - YES.
Stephen, I will clarify exactly what I mean.

I am not saying that Merlin cannot allow new things to be done.  That would
be like trying to kill Merlin by asfixiation.  I am saying that Merlin cannot
have a *different* way of doing the *same* thing.  For instance, either all
containers use the "urn:" notation or none do.  All containers have the same
core set of metadata or none do.  We need to standardize the RULEs, not
necessarily the implementations and featuresets.

To that end, we need to focus on the AMTAGS proposal and the Context
clarifications.  Currently, there is a similarity in some of the 
component
definitions between Phoenix and Fortress, with Merlin being divergent in
these areas.


Slow down a moment - your providing some misleading information here.  
The AMTAGS spec as it stands today is simply insufficient with respect 
to both Merlin and Phoenix.  The work going on under the Avalon Meta is 
addressing a complete model - but as you are aware, "AMTAGS" do not 
include a declaration of a version. With consideration of this the 
revision to AMTAGS in the process of development is addresses a complete 
solution.  That revision is not yet complete as work still remains to be 
done with respect to Phoenix requirements. To be very clear - neither 
Phoenix nor Merlin support AMTAGS  because AMTAGS  are woefully 
insufficient to express a complete component contract.
Stephen, I am not going to start arguing with you on this.  I respectfully
disagree.  Nevertheless, if the spec is insufficient then the spec needs
to be upgraded.  That is what the community is for.


We cannot have Melin be divergent.  We need one spec to drive the user
expectations. 


One must be careful in how one positions something as divergent.

Which of the following existing and divergent characteristics within 
Merlin would you like to eliminate?

 1. ability to provide a complete meta-info model
 2. ability to incorporate legacy Avalon component models
 3. ability to incorporate non-Avalon component models
 4. ability to separate deployment versus runtime dependencies
 5. ability to provide meta-data driven context creation
 6. ability to support context casting (e.g. BlockContext)
 7. ability to support alternative contextualization strategies (e.g. 
Servlet.getContext())
 8. ability to support distributed component semantics
 9. ability to auto-assemble and de-assemble components
You are completely missing the point.  See above for my clarifications.
There are different standards used for Merlin than are used for the
other Avalon containers for essentially the same thing.  Whether we
alter Merlin or the containers is something that we need to choose.
Divergent means that it deviates from established specification or
pattern.  In some cases the divergence can be seen as a plus, and in
other cases detrimental.
The purpose of this email is to get us focused on what it will take
to bring all the containers in line, as well as start the task of
making it doable.

So what's your opinion - are you conservative or democrat?



Think of the most conservative person you know (other than me), and I
will likely consider him a liberal ;P
Seriously, what does that question have to do with the price of tea in
China?
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Merlin's Future with Avalon

[Farr, Aaron]

> -Original Message-
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
>
> To that end, we need to focus on the AMTAGS proposal and the Context
> clarifications.  Currently, there is a similarity in some of the component
> definitions between Phoenix and Fortress, with Merlin being divergent in
> these areas.

Perhaps to avoid any misunderstanding, how exactly is Merlin divergent? 

The meta-info and meta-data descriptors are different for all three
containers.  This includes assembly, lifestyle identification, and
configuration.  Deployment structure (jar vs sar) is different between all
three containers.  Support for lifecycle extensions, nested containers,
context extensions and values are different in all containers.

I'm confused as to in which area Merlin is especially divergent.

jaaron

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

RE: Merlin's Future with Avalon

[Leo Sutic]

> From: Stephen McConnell [mailto:[EMAIL PROTECTED] 
>
> One must be careful in how one positions something as divergent.
> 
> Which of the following existing and divergent characteristics within 
> Merlin would you like to eliminate?

None, and that's never been the issue.

The issue is this: Will Merlin keep being divergent in those
characteristics
or will there be any incorporation of the charcteristics into the core
Avalon code?

In short, are you willing to codify those characteristics as a standard
that
may not fulfill all your wants but will fulfill all your needs, and then
stick to that standard?

In particular, the characteristics may make it into the standard, but
your
implementation may not.

I think that's the issue.

> So what's your opinion - are you conservative or democrat?

http://www.theonion.com/onion3539/national_funk_congress.html

/LS


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

RE: Merlin's Future with Avalon

[Farr, Aaron]

> -Original Message-
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
>
> To make the same component run in two different containers, you have
> three options:
> 
> 1 - make the featureful one degrade - which is out of question
> 2 - make components require a specific container - you know
>  it's not best
> 3 - make the other container upgrade to the new features, or even
>  better make the two integrate into one that has the best of both

To clarify a bit:

I have several components which run in all three containers.
Programmatically, the differences are:

- Context entry key and value pairs (I stay away from the context)
- Meta-info/meta-data descriptors
- Deployment format (jar vs sar )

Complex blocks may also rely on some of the assembly level or container
services, but in most cases applications can be written fairly container
agnostic.

For Fortress, until we have servlet and cli platforms finished, you also
need some sort of loader for the container.  For Phoenix, the biggest
trouble I've had is with older blocks that import BlockContext or some of
the other Block specific classes.

Merlin is actually the best at this because there is a strict separation of
component vs container concerns.  Stephen's done a very good job ensuring
that Merlin applications do not need to import any merlin specific classes.

> Merlin has cool features? Cool! When will it become *the* Avalon
> container? What is missing for it to become so? What does Fortress have
> that cannot and/or will not put into Merlin?

Merlin has some _very_ cool features.  If it does not become *the* Avalon
container, then it definitely is laying the groundwork.  I cannot think of
any standard Avalon 4 contract provided by Fortress or Phoenix which is not
also supported in Merlin -- though I may be wrong.  

My concern actually is that Merlin provides a number of features and
extensions which are not yet available in the other containers.  The choice
this brings up is to either port such features back into other containers
(convergence) or for each container to specialize in its respective areas
(divergence).  As long as the end developer could trivially port
applications from one container to another, then I don't think divergence is
necessarily a bad thing.

In terms of Merlin diverging from the other Avalon containers, I think this
has mostly been a matter of semantics (type vs component) than it is
compliance with the Framework.

jaaron

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

Re: Merlin's Future with Avalon

[kristian meier]

Nicola Ken Barozzi wrote:

kristian meier wrote, On 17/07/2003 9.02:

and I also would appreciate a beta release and hope I will find some 
time to put hand on some improvements here and there.


What would you think of a "Milestone" release? Which means that it's a 
fixed release to test, but things may/will change still.


sounds great . playing or using alpha code like Merlin it is clear that 
things may/will change.

it is much nicer to have such a tag to which I can fall back and a 
Milestone release also sounds like that everythings compiles, all tests 
run through etc.
with this you also have a kind of a cut, like finishing of a refactoring 
or something like this. and finally it is much easier to decide when I 
can switch to a new build.







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

Re: Merlin's Future with Avalon

[Paul Hammant]

Nicola,

...

We cannot have Melin be divergent.  We need one spec to drive the user
expectations. 


One must be careful in how one positions something as divergent.

Which of the following existing and divergent characteristics within 
Merlin would you like to eliminate?


Bullshit, Stephen. You are just generating negative energy, sit down a 
minute and think of it. It's *not* about how to remove "divergent" 
things, it's about how to *integrate* them. 
Please.  Such terms lead to division there is no need venture to 
that language.

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Merlin's Future with Avalon

[Nicola Ken Barozzi]

kristian meier wrote, On 17/07/2003 9.02:

and I also would appreciate a beta release and 
hope I will find some time to put hand on some improvements here and there.
What would you think of a "Milestone" release? Which means that it's a 
fixed release to test, but things may/will change still.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

Re: Merlin's Future with Avalon

[Nicola Ken Barozzi]

Stephen McConnell wrote, On 17/07/2003 3.37:

...
We cannot have Melin be divergent.  We need one spec to drive the user
expectations. 
One must be careful in how one positions something as divergent.

Which of the following existing and divergent characteristics within 
Merlin would you like to eliminate?
Bullshit, Stephen. You are just generating negative energy, sit down a 
minute and think of it. It's *not* about how to remove "divergent" 
things, it's about how to *integrate* them.

Berin said:
"Before I can be OK with that, we need to ensure that all user 
components are defined consistently across all containers.  The meta API 
separated out is a step in that direction.  We need to be assured that 
the same component used in Merlin will continue to function in Fortress, 
and vice versa. "

To make the same component run in two different containers, you have 
three options:

1 - make the featureful one degrade - which is out of question
2 - make components require a specific container - you know
it's not best
3 - make the other container upgrade to the new features, or even
better make the two integrate into one that has the best of both
Merlin has cool features? Cool! When will it become *the* Avalon 
container? What is missing for it to become so? What does Fortress have 
that cannot and/or will not put into Merlin?

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

Re: Merlin's Future with Avalon

[kristian meier]

The all important question is what is the developer interest in this
container? Who else is willing to put their eyes on it and time to
maintain it?
I don't know how or why I end up using Merlin and not Phoenix or 
Fortress (though there is also a Fortress container embedded somewhere). 
Merlin just fitted into the needs I had/have.

so right now we are using Merlin as prototyper for our EJB-appplication 
! that's why there is quiet an application deployed on merlin with more 
than one deployment scenario. I will definatly build merlin once a while 
and get everything running again - and find bugs and try to fix them as 
I have done in the past. and I also would appreciate a beta release and 
hope I will find some time to put hand on some improvements here and there.

with best wishes
Kristian


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

Re: Merlin's Future with Avalon

[Stephen McConnell]

Vinay Chandran wrote:

Berin,
 

The all important question is what is the developer
interest in this
container?  Who else is willing to put their eyes on
it and time to
maintain it?
I am . [ if it makes any difference :-))  ]

It makes a difference from my point of view!

Chers, Steve.

Regards,
Vinay
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


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

Re: Merlin's Future with Avalon

[Vinay Chandran]

Berin,
> The all important question is what is the developer
> interest in this
> container?  Who else is willing to put their eyes on
> it and time to
> maintain it?
> 
I am . [ if it makes any difference :-))  ]

Regards,
Vinay

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Re: Merlin's Future with Avalon

[Stephen McConnell]

Berin Loritsch wrote:

I hope this is not as ominous as it sounds, but I want to get a feel for
the community on the whole Fortress/Merlin/Phoenix scenario.  We 
currently
have two officially released and supported containers: Fortress and 
Phoenix.
Both have enjoyed a variety of eyes on the projects, and increased 
exposure
due to their release status.  Now Merlin is nearing the point where it 
would
like the same benefits of Fortress and Phoenix.

Before I can be OK with that, we need to ensure that all user components
are defined consistently across all containers.  The meta API separated
out is a step in that direction.  We need to be assured that the same
component used in Merlin will continue to function in Fortress, and vice
versa. 


Berin:

If I take your "before I can be OK with that" statement literally, I 
should point out to you that there are things in Merlin that are just 
not possible in other containers.  These features (some of which have 
been recently exposed by Vinay in his post concerning custom service 
attributes) are beyond classic Avalon - they go into the area of 
distributed service management.  I am personally really interested in 
this area and I see lots of adventures in this realm - realized and 
delivered through the Merlin platform - as not necessarily compliant nor 
consistent with existing Avalon containers - in fact these very features 
are pushing beyond the "accepted" envelope.

Is that a good thing - YES.

To that end, we need to focus on the AMTAGS proposal and the Context
clarifications.  Currently, there is a similarity in some of the 
component
definitions between Phoenix and Fortress, with Merlin being divergent in
these areas.


Slow down a moment - your providing some misleading information here.  
The AMTAGS spec as it stands today is simply insufficient with respect 
to both Merlin and Phoenix.  The work going on under the Avalon Meta is 
addressing a complete model - but as you are aware, "AMTAGS" do not 
include a declaration of a version. With consideration of this the 
revision to AMTAGS in the process of development is addresses a complete 
solution.  That revision is not yet complete as work still remains to be 
done with respect to Phoenix requirements. To be very clear - neither 
Phoenix nor Merlin support AMTAGS  because AMTAGS  are woefully 
insufficient to express a complete component contract.

We cannot have Melin be divergent.  We need one spec to drive the user
expectations. 


One must be careful in how one positions something as divergent.

Which of the following existing and divergent characteristics within 
Merlin would you like to eliminate?

 1. ability to provide a complete meta-info model
 2. ability to incorporate legacy Avalon component models
 3. ability to incorporate non-Avalon component models
 4. ability to separate deployment versus runtime dependencies
 5. ability to provide meta-data driven context creation
 6. ability to support context casting (e.g. BlockContext)
 7. ability to support alternative contextualization strategies (e.g. 
Servlet.getContext())
 8. ability to support distributed component semantics
 9. ability to auto-assemble and de-assemble components


Beyond that, I have nothing against Merlin.  It solves some user needs,
otherwise it would not have been written.  I think with more eyes on it,
the internals will likely be improved without breaking the client's
code.


I would go further than the assertion that it "solves some users 
needs".  What Merlin is about is pushing the envelope on what 
containment is all about.  It's a complex platform that is very 
adaptive.  Most importantly - it is a platform that is forcing this 
community to address a bunch of issues.  It forcing us to come to terms 
with the notion of "portability", "interoperability" and in due-course 
"distribution".  Merlin is an adventure - even more important - Merlin 
will continue to push the envelope - it will (if I have anything to do 
with it) challenge accepting thinking, go further and more courageously 
than any container has gone before (umm, sounds like Star Trek - but 
that kind of makes sense - its about going way beyond - into things we 
haven't solved).

I think this is a good thing!

So what's your opinion - are you conservative or democrat?

Cheers, Steve.

The all important question is what is the developer interest in this
container?  Who else is willing to put their eyes on it and time to
maintain it?
--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


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

RE: Merlin's Future with Avalon

[Jim Alateras]

> -Original Message-
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 17, 2003 6:15 AM
> To: Avalon Developers List
> Subject: Merlin's Future with Avalon
>
>
> I hope this is not as ominous as it sounds, but I want to get a feel for
> the community on the whole Fortress/Merlin/Phoenix scenario.  We currently
> have two officially released and supported containers: Fortress
> and Phoenix.
> Both have enjoyed a variety of eyes on the projects, and
> increased exposure
> due to their release status.  Now Merlin is nearing the point
> where it would
> like the same benefits of Fortress and Phoenix.
>
> Before I can be OK with that, we need to ensure that all user components
> are defined consistently across all containers.  The meta API separated
> out is a step in that direction.  We need to be assured that the same
> component used in Merlin will continue to function in Fortress, and vice
> versa.
>
> To that end, we need to focus on the AMTAGS proposal and the Context
> clarifications.  Currently, there is a similarity in some of the component
> definitions between Phoenix and Fortress, with Merlin being divergent in
> these areas.
>
> We cannot have Melin be divergent.  We need one spec to drive the user
> expectations.
>
> Beyond that, I have nothing against Merlin.  It solves some user needs,
> otherwise it would not have been written.  I think with more eyes on it,
> the internals will likely be improved without breaking the client's
> code.
>
> The all important question is what is the developer interest in this
> container?  Who else is willing to put their eyes on it and time to
> maintain it?
>
We have used Phoenix for 2 applications over the last 12-15 months and it
has served us very well indeed. For our next project and we will look into
Merlin before making a decision on which container to use.

cheers



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

Re: Merlin's Future with Avalon

[J Aaron Farr]

On Wed, 2003-07-16 at 16:14, Berin Loritsch wrote:

> We cannot have Melin be divergent.  We need one spec to drive the user
> expectations.

Agreed on both points.

I really don't care if Avalon has one container or five.  The important
part is simplicity from the end user (component developer) perspective.

> The all important question is what is the developer interest in this
> container?  Who else is willing to put their eyes on it and time to
> maintain it?

I am interested in it.

We have one Fortress application running in production now, but I hope
to use Merlin for the next wave of applications currently under
development.  There are a number of features to Merlin, such as the
integration with Maven repositories and direct launching of block.xml
files, which make it very attractive.

-- 
 jaaron  


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