avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [Vote] Mediation or not.
Date Mon, 26 Aug 2002 21:13:31 GMT

Leo Sutic wrote:
>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com] 
>>Avalon Committers : I'd like a vote of confidence please.
> +100 for trying, mate.
> +1 for keeping on trying, but
> +0 for your chances of success.

*sigh* *nod* *sigh*

> Mediation is only useful if the two sides want to get along. So far
> it seems like Peter and Stephen are fine with making any compromise and
> that
> they are happy to include any Merlin/Phoenix feature - as long as the
> end result
> is *exactly* like they intended it all along. 
> The man with the plan, and Heaven help anything that the straight line 
> from either of them to their goal intersects. I don't mind that - with 
> an exception I'll get back to below - design by Guru is a remarkably 
> fast way of getting good stuff done fast fast fast, because you don't 
> have to spend time explaining the vision or plan and align everyone. 
> I'm not the slightest surprised at Peter's two-week attribute-driven 
> blitzkrieg - if anything it is that the business logic wasn't finished 
> after 2w, but I guess management takes time.


> I'm not sure that the Phoenix way is the way to go - too static. I'm not
> sure the Merlin way is the way to go - too much magic. 

Good summary, I agree.

> All I want
> is no changes to Framework. As long as Avalon/Framework has all
> contracts
> and all classes needed to write a container or a component, I'm fine.


Some are more involved in containers here, some in components, I'm 
surely with Leo on the framework :-D

>                                 ------------
> Nicola's proposition of containers within containers seems like a
> worthwhile
> solution for now - only problem being how you handle lookups:

Yup, you said it ;-)

> Container X hosts component A. It also hosts container Y, which hosts
> component B:
>   X -----+----- A
>          |
>          +----- Y ----- B
> Now when A does lookup(B.ROLE) (to use ECM notation, you know what I
> mean),
> X must not only check 
>   + itself (does X contain a B?)
>   + it's parent CM (does the parent CM have a B?)
> as is done currently in the ECM, but also
>   + all its embedded containers (does Y have a B?)
> Meaning that Y must somehow expose a Container interface (I guess
> similar to the ServiceManager interface).

Yes. A Container is a Component, and as such should have his interface.

> If we can have this, then 
>  + Phoenix can evolve in any way Peter sees fit.
>  + Merlin can evolve in any way Stephen sees fit.
>  + <insert name of next great container> can evolve 
>    in any way <author> sees fit.

And eventually converge when they see the advantages of the other stuff.
Peter said it right: we are not ready yet to do a uber-all container, 
and probably never will because we will *always* come to some point that 
new Containers will come onto the scene, with new functionality.

Let's not get buried into something we're not ready yet to do, but let's 
also manage multiple Containers effectively.

> I also think this will have the least impact on Merlin/Phoenix. 
> Phoenix is already embeddable (I think), and Merlin surely is.


Also, if we could decouple the base frontends from Phoenix, as I already 
hinted to Paul, we could have a very neat thing.
Not compulsory, but nice IMHO.

> And the problem of trying to come up with the one true container pretty
> much disappears. Best of all: Avalon/Framework is unchanged.

[snipped subtle Leo-Rant ;-)]


With regards to the PhoenixBlockContext...

I don't like the solution Paul stated as a definitive solution to the 

As I already said, I don't even like the idea that Cornerstone 
components need to be bound necessarily to Phoenix.

I understand that Peter is addressing these issues, and I feel confident 
he will.

BTW, I have taken time to look what usage there is in Cornerstone about 

There are only 4 classes, and this is part of AbstractFileRepository, 
written by... you go and see, get ready for a surprise :-)

     public void contextualize( final Context context )
         final BlockContext blockContext = (BlockContext)context;
         m_baseDirectory = blockContext.getBaseDirectory();

Now, this can be easily done like Stephen says:

 > I really think that resolution of the attribute issue is the issue
 > that needs to be dealt with in the short term.
 > Consider the following:
 >   // Phoenix dependent version
 >   File file = context.getWorkingDirectory();
 >   // portable component version
 >   File file = (File) context.get("avalon:home");

This is IMNSHO a wrong way of using a context.
context has been casted to BlockContext, a thing that should be done 
only on objects given by a ServiceManager.

In fact, a service is gotten by role, a Context is given as-is.

It's plain wrong that a Context be cast, it should be used only via keys.

Seeing all the commented out methods of Blockcontext, I think Phoenix 
developers agree.

 > The attribute documentation over
 > on excalibur/container/src/xdocs/attributes.xml provides a good
 > picture of what's needed on common context keys.

Let's standardize on these.

Like lifecycle interfaces get a stamp of approval when there is a valid 
use-case for them, so we should do with Context attributes.


Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message