avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Under Merlin's hood
Date Fri, 05 Mar 2004 04:56:20 GMT

Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:

>> And just how many competing products and integral architectures is
>> Cocoon endorsing, publishing and supporting?  Just how many mail 
>> servers is the James community supporting?  How many different 
>> component architecture is Turbine backing (as opposed to the number
>> of architectures they have to deal with).
> 
> 
> Fallacy. I was talking about *community* and not about *product*.

Yes - I know you were addressing community.  I was referring to the
foundation on which a community can function well.  So long as we have
different platforms we have this forever on-going debate about what is
right and what is wrong as opposed to good old fashioned getting in
there, supporting, evolving, influencing, and ultimately changing what
it is that we believe in.

The difference between here and there is about making some choices
together and molding and sculpting - its about the the feeling I had
looking looking code in castle - feeling quite at home, and rather proud
of myself - and curious about why your doing something different.

That's community!

>> And how does this impact a community. It means that the community 
>> is a community because is bound be a single idea, a vision, an 
>> ideal - call it what you want.
> 
> 
> Agreed.
> 
> 
>> Put in place one solution.
> 
> 
> Solution for whom, for God's sake.

For Avalon, Apache, our users, James, Cocoon, Turbine, and the Apache
Directory Project, and you can count me in under the "users" category.

> Thats the point: for a very particullar audience who wants to feel 
> using a J2EE like container.

I don't see things in the same light as you do.  But let get down the
real point your raising.  Your depicting Merlin as a J2EE platform. That
in my opinion way off the mark because the Merlin development (and the
opinions of the people contributing to merlin) go well beyond that
reference point - something much better, much cleaner, a complete
quality IOC component and service management solution.

But don't get me wrong - management is an intrinsic element of where I
believe the industry is going and with the explosion of users, servers,
protocols and components out there management around these will become
critical.

>> Kill the rest and you change the equation.
> 
> And push your decision through their trhoat.

Basically we have the cowboys on the left and the city-guys on the 
right.  The cowboys want to play thing fast-and-loose and the city-guys
want to play by the numbers.  It just so happens that the city guys have
pulling something together that out-guns the cowboys. I don't want want
to appolagise for that but we do need to deal with it.

Your suggesting that this is a case of me "pushing my decision through
their throat". Well that's not exactly the case.

First off - my decision is academic (as you have already pointed out to
Niclas) - the opinion of one is no more or no less than than any other.
What is not academic is the result of the participation.  Now here is
where we get to the crunch.  Cocoon is hung out on a string and this
means an opportunity for the cityguys to step in and close once and for
all the duplicity in Avalon.  What I'm not interested in hearing about
is the next great meta adventure. Geeez!.  I'm not terribly interested
is hearing about a Sally or Nancy container either.  What I am
interested in - is closing an issue that Cocoon have to deal with and
at the same time closing the Avalon divide.

So what about the cowboys?  OK when you brush of the dirt and dust,
underneath these are just regular guys.  And you know what? There is
lots of stuff to do - we have only finished main street - plans for
downtown are on the drawing board.

>> I'm not concerned about people leaving because we take a decision. 
>> I am concerned about people leaving because we don't a decision.
> 
> 
> Maybe the majority thinks Merlin SHOULD be the future of Avalon, the
>  *reference* implementation. I'm included in this group. But I - and 
> others I think - disagree that it will happen as the way it is *now*.
> 
> 

It is going to have to happen.  We are causing ourselves too much damage
through protracted indecision. This is not about "which container" -
that's a done deal.  This is about accepting that its a done deal.  The
sooner we get past this point the better it will be for you, me, and
everyone else.

> And when Aaron says: I don't want the damn repository you'll came 
> with "whats the *real* reason to not want it".

Honestly I had absolutely no idea where you were coming from. I was
feeling really good about your stuff (feeling just a tad proud myself),
and then your jumping at something that wasn't there. If you had taken
an extra 20 mins you may have read more about the structural and
security implications of Aaron's suggestion.  You may also have read
some opinions about how some of the underling objectives could be dealt
with differently, and why Aaron's suggestion is probably inevitable for
web-app scenarios.  But OK - whatever - we'll get back to the subject
when the dust has settled.

> Your words: "Merlin needs to be break down 'til it becomes Avalon". 
> For every day it seems like to more and more distant goal.

As far as I am concerned Merlin is Avalon's future.

I don't think I've exactly kept this as a hidden agenda (in fact I think
its a stated objective somewhere).  But let's take this a step further.
Here is a predication - Merlin will break down and become Avalon.  It
will be "The Avalon Container".  It will use "That Avalon Meta Model",
it will manage component composition through "Avalon Composition" it's
runtime will be executed under "Avalon Activation", it's
internatilization system will be "Avalon i18n", etc...

And guess what? Anyone can step up and be part of that process, get in
there, make it evolve, contribute, push in news ideas, refactor, revolt.
Heck - that's what the community rules embrace.  Its in this context
that we bring in more committers, grow the community, enable other
people to pick up stuff that we are learning. End-game? A sustainable
community that takes ownership and goes places we haven't even thought
about.

> And you take the defensive when someone says "I don't want the 
> repository!"

No.

I may be slow, my typing sucks, I know Niclas hates the way I format
code, and Alex hates the complexity I put into builds, Leo hates my
notion of architecture and the other Leo simply hates the names I give
things.  But aside from all of that (heck nobody's perfect) - I do want
to help, but I want to understand things before I make conclusion!

That means asking question.  That's why I asked Alex a bunch of
questions when he started talking about turning Merlin inside out, it
the reason we ended up with a clean activation model - not from me - but
from Niclas asking too many dam difficult questions.  It's the reason I
asked Aaron what motives were underling his proposal.

> Go[t] it?

Yep - it's right here on the tip of my finger.

>> So lets get to the point.  One product architecture.  One product 
>> implementation. If someone doesn't like that product then they need
>>  to get their butt in gear and do something about it. And a united 
>> community will make sure it evolve.
> 
> 
> Ok, will do.

Good.

We are on the same page.

>> Now is the time to make that decision.
> 
> Now its time to get consensus. Please, get your butt in gear and make
>  your proposal.


PROPOSAL (Aaron - you ready?)

1. We move Fortress into sustainable retirement
2. We move Phoenix into terminal retirement
3. We update our website and re-position Avalon on Framework
    and the core facilities within Merlin
4. We bring Avalon Components up-to-date with the Meta Specs
    (while maintaining legacy support for Phoenix meta)
5. We move facilities to Avalon Components

And outside of the formal proposal, I would be really happy if anyone
wants to join me in taking on what is necessary to deliver a solution
for James, Cocoon and Turbine - based on Avalon supported products with
the collaboration of the respective communities, and through this
process deliver the necessarily legacy support for transioning users.

Stephen.

-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|



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


Mime
View raw message