avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Carapetyan <p...@datafundamentals.com>
Subject Re: The need for 'hints'
Date Thu, 20 Jun 2002 12:19:45 GMT
Stefano brings up what seems to be my biggest question:
*What is Avalon for?*
If the answer is anything other than pluggability or portability of 
components, this needs to be clarified.
  Loose coupling is the only reason I am here. For everything else, 
straight OO is dumber, easier,  more direct.

If this is the case, then the first thing that needs to be shown on the 
Avalon page is not explanation of IoC and SoC but instead when to use 
Avalon and when not to.

This would also cut down on a lot of the back and forth, as it appears 
that the heart of the differences is not in how to do things, but what 
is trying to be done. If we don't agree on what we are trying to do, 
then how to do it can be argued until the cows come home.

<regarding Cocoon only>
Having Cocoon stuck with Avalon 4 seems like a non-problem, as Avalon 4 
is a miles ahead of straight OO which would be the alternative. So, what 
is the problem if Avalon moves ahead and Cocoon sticks at 4 for a year 
or two, if a migration tool really wouldn't do the trick?
</regarding Cocoon only>

Nothing below but snips of Stefano's comments:

Stefano Mazzocchi wrote: <snipped all up, without snips showing>

>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
>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.
>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)
>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. 
>I call for a restate of the Avalon's project charter!
>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.
>Ok, it's clear now: Cocoon should NOT be using Avalon 5 for those
>components which lookup mechanism's control cannot be completely
>Anybody against this?

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