Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3D108E32.936AD976@apache.org>
Date: Wed, 19 Jun 2002 15:59:14 +0200
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: The need for 'hints'
References: <5.1.0.14.2.20020611100456.00b277d0@mail.optushome.com.au>
	 <5.1.0.14.2.20020616151518.00bbe680@mail.optushome.com.au>
 <5.1.0.14.2.20020618091645.00b3b888@mail.optushome.com.au>
 <3D0F66BA.29DDCF2B@apache.org> <3D10513A.8040405@osm.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Stefano:
> 
> Image that you have to live with the rule that assembly infromation may
> not be supplied to a container as a method argument.   Imagine that this
> is a really strinct rule - that is enforced by generic containers.

Ok, let's assume that.

>  There are two conclusions you can draw from this:
> 1.  that it is a components responsibility to publish assembly criteria
> and functional constraints formally
> 2.  that criteria that connot be expressed at a type level (i.e. in meta
> declarations) is criteria that is application specific in which case the
> component should be requesting a component capabable of servicing the
> application level semantics
> 
> >
> >then, what do I gain from A5?
> >
> 
> Let me rephrase the question to "what do I gain from the seperation of
> concerns of assembly for application context" and the answer to that is
> portability of components across containers.

Bingo, I think we touched the nerve: all Cocoon components where forced
to be Avalon components, even those who cannot (nor should not) be
portable across containers.

That's admittedly a design mistake. We have been abusing Avalon since we
used it too much, even where it would have made more sense to do our own
stuff.

> >Ok, great. So, what's wrong with
> >
> > lookup(role, policy)
> >
> >?
> 
> The most significant thing that is wrong about this is that it places
> infromation about assembly into the code of the component.  Keep in mind
> that the lookup operation is only concerned about assembly.  As soon as
> something goes into the lookup operation that is not opaque and managed
> within the componet namespace, your eliminating the potential for
> validation and assembly tools that are dependent on the expression of
> this information at a type level.  For example, I can assemble a
> component type graph without instantiating a single component.  I can
> validate that assembly without instantiating a single component.  But if
> you put structure into the role argument, or if you supply a policy
> argument, your introducing criteria that must be really formall defined
> (so that generic containers can undersand it in an interoperable
> fashion), and you eliminating the potential for pre-instantiation
> validation (i.e. deferring validation until the lookup request hits the
> component manager).

Yes, I feel I beging to see your point and Peter's as well: if the goal
is to have avalon components safely portable across containers, we must
complete the inversion of control and a 2-d lookup mechanism doesn't
allow this to happen.

This forces Cocoon *not* to use Avalon for certain things like its
internal intrinsically container-tight components.

> What sort of information do you want to supply via lookup ?
> How does this information relate to existing component types and
> instantiated component instances managed by the container?
>  From you answer I'll try to explain how this can work, and what the
> implications are relative to the container and the component.

No, no, with the light of 'easing portability of components' I agree
that it makes no sense for us Cocooners to push in this direction
because they are different concerns.

I'm still worried about the fact that it will be harder to push in the
direction of A5 if less functionality is provided to Cocoon than A4
(which works well for us today) and more stuff will have to be rewritten
by ourselves directly.

I do see the need for it, since it's true: Cocoon uses Avalon to manage
the lookup of both *real* Avalon components (those that should be
portable) and for cocoon components (that should *not* be portable
because it wouldn't make any sense to try to do so)

> Its puts assembly semantics into code and that eliminates the potential
> for validation before execution.  Elimination of this step eliminates
> the potential for real management (i.e. suite type management).

I think the catch-22 issue comes from the fact that Cocoon used Avalon
too much, even where it didn't make sense. You guys now want to refactor
it and clean its mistakes and I agree that Cocoon should not force bad
design decisions because of past abuse.

At the same time, the inertia of Cocoon is *very* big now and with
several books coming out, it's hard to change things so deeply without
pissing everybody off. 

Anyway, I'm changing my -1 to the removal of lookup(role,hint) to a +0
not to interfere with A5.

As for Berin's proposal, I think that the use cases you outlined, not
all of them belong to Avalon.

I call for a restate of the Avalon's project charter!
 
> >
> >
> >>The key points are;
> >>
> >>* separating the lookup key for dependency from set of constraints
> >>associated with dependency
> >>
> >>
> >
> >Absolutely, I agree they should be decoupled, this is exactly why I
> >liked the 2-d lookup approach where one dimension connected with the
> >dependency and another one to the constraints associated with the
> >dependency.
> >
> 
> But its in the code!!
> This information does not need respide in the code.
> This information can be used in a maner which is orthogonal to the
> component.
> This information is part of the structural contract and must be declared
> in order for delivery of components.

Unfortunately, there are cases (Cocoon is one of them) where this clear
separation is not possible.

But I do agree that the fact that Cocoon should use Avalon even in those
cases where this is not possible was an arbitrary decision.

> >>* simplifying interface from user perspective and making it harder to abuse
> >>the
> >>* separating out separate stages/views (ie assembler vs develoepr view).
> >>* easing product evolution
> >>
> >>
> >
> >These are highly subjective and I won't question them.
> >
> >Like I said, I like what I see, but I fail to see why a 2-d lookup space
> >is a bad thing, even with the context you give me.
> >
> >
> 
> Because its in the code - its in the code - its in the code!

:)

Ok, it's clear now: Cocoon should NOT be using Avalon 5 for those
components which lookup mechanism's control cannot be completely
inverted.

Anybody against this?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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